MIDI-Routing und Setlist-Management für iOS

  • Ersteller JohannesD
  • Erstellt am
aber effektparameter und Volume kann man doch bei mir im Mixer view einstellen. mit Performance view meinst du das hinzufügen von neuen Sounds? geht doch auch. also mir ist nicht ganz klar, was fehlt. ich will dich ubrigens jetzt nicht von meiner App überzeugen, sondern dich nur verstehen :)
 
Hey Johannes,

ich weiß nicht, ob die Effektparameter, die bei dir einstellbar sind, sich auf die VSTs beziehen oder auf die Audio Inputs. Ich brauche die z.B. lediglich auf den Audio-Inputs. Da reicht leider ein Dreiband-EQ nicht aus. Für Livemixing brauch ich vier Bänder und alle zumindest semiparametrisch. Außerdem Compressor und Reverb.
Ich hab dir nochmal etwas angehangen.

Volume kann man bei dir auch verstellen, richtig. Aber die Anzeige wäre mir viel zu klein, um genaue Einstellungen vorzunehmen. Da brauche ich lange und große Fader.
 
Interessant, wie die Profis tricksen. Ich habe mal einen Bericht über die Keyboarder von Peter Fox gelesen. Die setzten ein Sampling-Verfahren ein, das so ähnlich funktioniert. Die spielen dann irgendwelche Tasten hintereinander, auf denen kurze Passagen des Orchesters gesampelt sind, die in der Abfolge dann die Melodie ergeben. für mich wäre das glaube ich nichts :)

Kann ich verstehen. Für mich war es auch sehr gewöhnungsbedürftig, als ich diese Musicals gespielt habe, wo man diese Spielweise erst erlernen musste. Andererseits trifft das Abkoppeln von gegriffener von klingender Tonhöhe schon ziemlich genau die Tendenz, die bei Keyboards ja ganz allgemein zu beobachten ist. Ob Sequenzer, Arpeggiator, Korg-Karma-Funktionen, Begleitautomatik, Yamahas Multi-Pads, Korgs Realtime Pattern Play und Rolands Realtime Phrase Sequences - alle Spielhilfen dieser Art laufen darauf hinaus, daß die gegriffene von der klingenden Tonhöhe abgekoppelt wird. Die gegriffene Tonhöhe wird zu eingegebenen Daten, und die klingenden Tonhöhen werden zu auszugebenden Daten. Dazwischen liegt ein Algorithmus, der möglichst flexibel, variabel (und natürlich musikalisch eigenständig perfekt ;)) arbeiten sollte.

Eigentlich wird es an der Zeit, Keyboards zu bauen, wo man diese Algorithmen selbst mit einer einfachen Basic/C-ähnlichen Sprache schreiben kann. Max/MSP muss wohl so eine Sprache sein, läuft aber eben nicht auf einem Keyboard. Eigentlich ist es widersinnig, daß alle paar Jahre jemand mit neuen MIDI-Verarbeitungsalgorithmen den Markt betritt (wie Stephen Kay mit Karma), und das dann nur auf einer Platform und nur auf bestimmten Geräten mit bestimmten Parametern läuft. Sorry, kleiner philosophischer Exkurs :)...

Ich meine, mein Verfahren wäre kompliziert. Deine Lösung dafür ist echt gut. Statt ner Formel einfach die Werte angeben, geht ja bei 127 gerade noch. Habe das schonmal in einem Beitrag von dir Ich glaub im MIDI-P Thread gelesen. Fürs iPad könnte man sich da ne gute Eingabemöglichkeit überlegen.

Ja, gerade ein Touchscreen bietet sich doch eigentlich an, um eine Grafik mit 127 Werten zu editieren: eine y-Achse mit den Werten 0-127, eine x-Achse mit dem erwähnten Array, und dann kann man mit der Hand Velocity-Kurven malen :D Ich breche mir ja schon einen ab, wenn ich so eine Grafik unter Visual C++ mit Mausbewegungen (Klicken und Ziehen) editierbar machen will.

HaraldS schrieb:
Damit meine ich z.B. eine deutliche CC#7 bzw. CC#11-Anzeige als Treppe über den gesamten Bildschirm. Diese Werte sollten auch verfolgt werden und von Setup zu Setup weitergegeben werden können.
Was meinst du mt dem letzten Satz?

Damit meine ich folgendes Szenario: ich spiele einen Strings-Sound und verändere seine Lautstärke über das Expression-Pedal, das CC#11 an den Sound sendet. Dann schalte ich aufs nächste Setup, in dem z.B. zwei Stringssounds mehr Stereobreite erzeugen, z.B. wenn im Refrain eines Songs die Strings größer klingen sollen. Dann sollte der CC#11-Wert beim Verlassen von Setup#1 direkt an Setup#2 (und damit an dessen Sounds) weitergegeben werden, damit keine Lautstärkesprünge entstehen. In Musicals gibt es dieses Szenario sehr oft, daß die Lautstärke ein Parameter sein muss, der allen Sounds übergeordnet ist. Das meinte ich mit "weitergeben" ans nächste Setup. Auch im Bandkontext macht das natürlich Sinn.

Harald
 
Hey Johannes,
... Volume kann man bei dir auch verstellen, richtig. Aber die Anzeige wäre mir viel zu klein, um genaue Einstellungen vorzunehmen. Da brauche ich lange und große Fader.
diese Problematik kann man mit touch-Gesten anscheinend recht effizient angehen: in (ich glaube MidiTouch) wird die Bewegung des aktuellen Faders skaliert, wenn ein zusätzlicher Finger auf der Oberfläche liegenbleibt. Man schiebt mit Zeige-, Mittel-, Ringfinger und sobald der Daumen dazukommt, wird die Bewegung runtergebremst. (gibt sicher noch mehr Methoden)

cheers, Tom
 
Ich habe mir ein ziemlich komplexes Template erstellt, wo ich für jeden Audioinput (16 an der Zahl) einen eigenen ChannelStrip zur Ansicht hatte inklusive EQ, Compressor und Reverb. Als ich das dann an das iPad überspielte, fehlte 90% der Arbeit. Als ich den Editor geschlossen und wieder geöffnet hatte, hier das gleiche: Alles weg!
Sehr sehr ärgerlich. Das liegt daran, dass der Editor keine Dateien schreibt, die größer 512kB sind. Ich hoffe, das wird bald gefixt...
Sorry 4 OT, aber das muss anders gehen: du verwendest die Regler für deinen Channel-Strip nur ein einziges Mal in deinem Template (das spart Platz), hast aber einen Satz von Variablen für jeden Mixer-Kanal (diese senden Midi-Nachrichten bei Veränderung). Du fügst zusätzlich einen Kanalwahlschalter in dein Template ein und verwendest für jeden Regler Scripts, um bei Veränderung des Reglers die Werte der entsprechenden Variablen zu ändern (abhängig von der Stellung des Kanalwahlschalters). Schliesslich verwendest du ein "Update"-Script, das bei einer Kanaländerung aktiviert wird, die aktuellen Werte der entsprechenden Variablen liest und die Stellung der Regler anpasst (sieht dann so aus wie mit Motorfadern bzw. Drehreglern mit LED-Kränzen: alles springt bei Kanalwechsel an die richtige Position).

Ich benutze so etwas gerade für eines meiner Lemur-Templates, zugegeben mit viel weniger Variablen.

Grüsse,
synthos
 
Was natürlich die optimale Lösung wäre, wäre, das iPad (oder welches Touchscreengerät auch immer) nicht selbst als MIDI-Prozessor zu nehmen, sondern nur als Ein- und Ausgabegerät. Das heißt, man hat einen dedizierten Prozessor, eventuell noch mit eigenem Programmspeicher (kann, muß aber nicht), auf jeden Fall aber mit einem ganzen Sack voller MIDI-Buchsen. Über USB (kann man dann handelsübliche Kabel für nehmen) wird, sagen wir, ein iPhone oder ein iPad einzig als Controller angeschlossen, ähnlich wie die Miditemp-Fernbedienung, vielleicht noch als Programmspeicher (was dann das Dumpen wie bei einer Miditemp überflüssig machen würde). Da die jeweilige App nur kontrollieren muß, aber nichts Zeitkritisches tut, und da wir nicht mit proprietären Anschlüssen (*hust* iPad-2-Dock *hust*) herumhantieren, wäre hier sogar der Einsatz von Android- oder WebOS-Geräten mit einer entsprechenden App denkbar.

Die Sache ist ja die: Auch wenn iOS wesentlich kleinere Latenzen hat als die Konkurrenz, kann man damit leider Gottes nicht den Datenwust durchsetzen, den jeweils 8 oder gar 16 voll belegte Ein- und Ausgänge (das sind dann 256 eingehende MIDI-Kanäle, die auf 256 ausgehende MIDI-Kanäle geroutet werden) inklusive freiem, beliebigem Mergen von Signalen sowie Filtern, Controllertauschen oder gar Verändern der Velocity-Kennlinie verursachen.

Das Geniale beim Einsatz eines Tablet als Controller einer MIDI-Patchbay ist, daß man das schön grafisch machen kann, wie wenn man z. B. was in Reaktor bauen würde oder meinetwegen im Nord Modular Editor. Mit Multitouch könnte man einen MIDI-Anschluß aufziehen und hätte die 16 Kanäle vor Augen, so daß man nicht nur Buchsen, sondern Kanäle routen kann. Man hätte auch immer seine Routings im Blick. Modifikatoren könnte man mit in die virtuelle Verkabelung reinschalten, die wären dann auch sichtbar.

Eventuell wäre noch ein Setlistmodus denkbar, in dem man Programme in einer bestimmten Reihenfolge auflistet. Dazu noch dicke Triggerflächen für vor und zurück.

Hab dann mal gelesen, dass das mit der PMM88E besser funktionieren würde, die geht mir aber meistens für zu viel Geld über'n Tresen, mehr als mir diese Sache bisher wert war.
Das geht mit der E recht gut, aber nachdem sie damals teurer war, ist sie heute seltener, weil mehr Leute eine haben wollen.
 
Die Sache ist ja die: Auch wenn iOS wesentlich kleinere Latenzen hat als die Konkurrenz, kann man damit leider Gottes nicht den Datenwust durchsetzen, den jeweils 8 oder gar 16 voll belegte Ein- und Ausgänge (das sind dann 256 eingehende MIDI-Kanäle, die auf 256 ausgehende MIDI-Kanäle geroutet werden) inklusive freiem, beliebigem Mergen von Signalen sowie Filtern, Controllertauschen oder gar Verändern der Velocity-Kennlinie verursachen...
das hat aber weder etwas mit der Datenmenge, noch mit 'Rechenleistung' zu tun, sondern würde einzig daran scheitern, dass es
a.) nicht sauber programmiert ist
b.) das Betriebssystem bestimmte andere Prozesse priorisiert (IOS dürfte aber weit weniger kritisch als windoze sein)

cheers, Tom
 
diese Problematik kann man mit touch-Gesten anscheinend recht effizient angehen: in (ich glaube MidiTouch) wird die Bewegung des aktuellen Faders skaliert, wenn ein zusätzlicher Finger auf der Oberfläche liegenbleibt. Man schiebt mit Zeige-, Mittel-, Ringfinger und sobald der Daumen dazukommt, wird die Bewegung runtergebremst. (gibt sicher noch mehr Methoden)

cheers, Tom

Multitouch find ich in diesem Zusammenhang nicht gut. Ich werde auch neben dem Spielen immer wieder an den Mixer ran gehen und da habe ich nicht die Zeit, die Gesten zu benutzen und bin froh, wenn ich überhaupt den richtigen Fader treffe :) Dann lieber große Fader, die ich bei Lemur ohne weiteres habe, wo ich sogar noch das Verhalten des Faders einstellen kann. Das ist einfach super! Vielleicht schaff ich es ja, morgen mal ein Video zu machen, was bisher steht. Musste ja jetzt ein wenig umdenken..


Sorry 4 OT, aber das muss anders gehen: du verwendest die Regler für deinen Channel-Strip nur ein einziges Mal in deinem Template (das spart Platz), hast aber einen Satz von Variablen für jeden Mixer-Kanal (diese senden Midi-Nachrichten bei Veränderung). Du fügst zusätzlich einen Kanalwahlschalter in dein Template ein und verwendest für jeden Regler Scripts, um bei Veränderung des Reglers die Werte der entsprechenden Variablen zu ändern (abhängig von der Stellung des Kanalwahlschalters). Schliesslich verwendest du ein "Update"-Script, das bei einer Kanaländerung aktiviert wird, die aktuellen Werte der entsprechenden Variablen liest und die Stellung der Regler anpasst (sieht dann so aus wie mit Motorfadern bzw. Drehreglern mit LED-Kränzen: alles springt bei Kanalwechsel an die richtige Position).

Ich benutze so etwas gerade für eines meiner Lemur-Templates, zugegeben mit viel weniger Variablen.

Grüsse,
synthos

Richtig, ich arbeite gerade daran mit Hilfe der Leute im Liine Forum. Ich werde das anders aufbauen. Dennoch kann es nicht sein, dass man bei 11% an die Grenzen der Lemur-App stößt und alles darüber nicht verarbeitet werden kann. Warum gibt es dann eine %-Anzeige? Eigentlich soll diese visualisieren, wieviel Platz noch im Template vorhanden ist.
Aber egal: Ich mach das nun über viele Variablen. Ist komplex, aber letzlich die beste und sauberste Möglichkeit!
 
Die Sache ist ja die: Auch wenn iOS wesentlich kleinere Latenzen hat als die Konkurrenz, kann man damit leider Gottes nicht den Datenwust durchsetzen, den jeweils 8 oder gar 16 voll belegte Ein- und Ausgänge (das sind dann 256 eingehende MIDI-Kanäle, die auf 256 ausgehende MIDI-Kanäle geroutet werden) inklusive freiem, beliebigem Mergen von Signalen sowie Filtern, Controllertauschen oder gar Verändern der Velocity-Kennlinie verursachen.

Du teilst also meine Bedenken hinsichtlich großer Setups, danke. Daher ja auch meine Idee, bestehende und bewährte Patchbays als Prozessoren mit einzubinden.

die 19" Emagics haben ja ihre Firmware im EPROM, und das kann man auslesen, weil gesockelt. Mit Kenntnis von CoreMIDI und MCS51-Assembler könnte man die Dinger nicht nur auf CoreMIDI umstricken, sondern auch vom Funktionsumfang her erweitern (zB mit dem, was Hermann Seib per externer Software da hinzugefügt hat). Wenn da nur kein 8051 drinstecken würde (ich hasse Intel-Assembler wie die Pest), wäre ich da längst beigegangen ... Einen Unitor8 MKII, der ein Flashrom zusätzlich zum EPROM für Updates hat, könnte man gar umschaltbar machen (per Software).
Nettes Bastelprojekt, aber am Besten was für Mehrere. Eine dezidierte Hardware auf Basis von MIDIbox verbietet sich aufgrund der Nutzungseinschränkungen, da müßte man dann schon selbst was auf die Beine stellen - oder eben was Bestehendes modifizieren.
 
Also, mindestens eines stellt sich hier heraus: daß ganz viele Musiker Bedarf an MIDI-Routing-Soft- und Hardware haben, und daß sie alle ganz unterschiedliche Bedürfnisse und Herangehensweisen haben. Und daß sich schon viele viele Leute Gedanken in die gleiche Richtung gemacht haben. Und das iPad inspiriert, ganz klar. Schon jetzt sehe ich es bei vielen Kollegen im Einsatz, z.B. zur Notendarstellung.

So wünschenswert eine hohe Rechenleistung, das Mergen von ~16 Ports, eine tolle grafische Oberfläche und beliebig viele Splitzonen auch sind...vielleicht ist es ganz gut, daß das iPad hier eine Hardware und damit eine Limitierung vorgibt, sonst würde man ja bei der Entwicklung so einer App nie zu Ende kommen.

Ach ja, ein lang gehegter Wunsch von mir wären Splitzonen, die mit den Händen mitwandern. So, dass ein Sound einer Hand zugeordnet ist, und nicht einer Tastaturzone. Da denke ich seit langer Zeit über verschiedene Algorithmen nach, wie man das programmieren könnte...

Harald
 
  • Gefällt mir
Reaktionen: 2 Benutzer
Ach ja, ein lang gehegter Wunsch von mir wären Splitzonen, die mit den Händen mitwandern. So, dass ein Sound einer Hand zugeordnet ist, und nicht einer Tastaturzone. Da denke ich seit langer Zeit über verschiedene Algorithmen nach, wie man das programmieren könnte...

Harald

Vielleicht hilfts dir, wenn du dir mal Mainstage anschaust. Da kannst du nämlich genau das machen!
 
Multitouch find ich in diesem Zusammenhang nicht gut. Ich werde auch neben dem Spielen immer wieder an den Mixer ran gehen und da habe ich nicht die Zeit, die Gesten zu benutzen und bin froh, wenn ich überhaupt den richtigen Fader treffe :)
ganz so extrem stellt es sich in der Praxis eigentlich nicht dar. Den Fader musst du eh treffen... sobald dann noch ein Finger auf die Oberfläche kommt (egal welcher), wird die ursprüngliche Bewegung verlangsamt. Dafür muss man nicht hinsehen.

Würde aber auch mit einem Finger funktionieren: einfach den Finger auf der Oberfläche lassen und vom Objekt wegziehen.
Die (horizontale) Distanz ergibt dann einen Skalierungsfaktor für den vertikalen Controller. So ähnlich arbeiten zB die dials im Electribe.
Feinfühligkeit und Reaktionsgeschwindigkeit, sowie das zielsichere Erkennen der Geste ist schon erstaunlich.
Bin mir nicht sicher, ob ich mich im Zweifel noch für 'echte' Drehknöpfe entscheiden würde... (gesetzt den Fall, es gäbe die Alternative)

Bei Lemur sind für so etwas aber die mitgelieferten 'physikalischen Eigenschaften' interessanter.

cheers, Tom
 
ich weiß nicht, ob die Effektparameter, die bei dir einstellbar sind, sich auf die VSTs beziehen oder auf die Audio Inputs. Ich brauche die z.B. lediglich auf den Audio-Inputs.

Jetzt weiß ich nicht, was du mit "VSTs" meinst (ich weiß schon was das ist :) ). Meine Effektparameter beziehen sich auf jedes Routing. Wenn ich also nur einen Piano-Sound spiele, erscheint da nur ein Strip. Wenn ich irgendwo einen zweiten spiele, dann zwei usw. Es gibt ja diese GM-Control Changes für Reverb usw. Die wollte ich da erstmal verwenden. Aber du hast recht, evtl. braucht man mehr. An der Stelle geht es dann schon sehr in die Richtung, das ganze angeschlossene Gerät zu steuern mit allen individuellen Parametern. Das geht natürlich nur, wenn die App etwas über die Geräte weiß (z.B. auch, wie viel Bänder der EQ hat). Hier muss ich natürlich erstmal Abstriche machen. Meine Intention des Mixer-Views ist es, zumindest die wichtigsten Einstellungen direkt anzubieten und übersichtlich darzustellen.

Volume kann man bei dir auch verstellen, richtig. Aber die Anzeige wäre mir viel zu klein, um genaue Einstellungen vorzunehmen. Da brauche ich lange und große Fader.

Ok! Bei mir ist es wie gesagt so, dass der Hauptfokus darauf liegen soll, die Einstellungen per Hardware Controller zu regeln, aber diese in der Software auszuwählen und dort auch eine Übersicht über die momentanen Werte zu erhalten. Regeln per Touch-Screen soll natürlich trotzdem gehen und da gibt es sicher Wege, die Genauigkeit der eingabe durch Vergrößerung etc zu erhöhen (Danke Telefunky für die Ideen).

Die Sache ist ja die: Auch wenn iOS wesentlich kleinere Latenzen hat als die Konkurrenz, kann man damit leider Gottes nicht den Datenwust durchsetzen, den jeweils 8 oder gar 16 voll belegte Ein- und Ausgänge (das sind dann 256 eingehende MIDI-Kanäle, die auf 256 ausgehende MIDI-Kanäle geroutet werden) inklusive freiem, beliebigem Mergen von Signalen sowie Filtern, Controllertauschen oder gar Verändern der Velocity-Kennlinie verursachen.

Du hast Recht, gäbe es aktuell ein Hardware-Produkt, mit dem das ginge, dann würde ich dazu die Software schreiben. Nur gibts das leider nicht und ich werde mich in naher Zukunft auch nicht der Aufgabe stellen, so eines auf den Markt zu bringen. Wenn dies jemand anderes tut, dann mache ich die GUI :) Solange es das nicht gibt, müssen die Leute, die wirklich so eine hohe Anforderung haben, auf ein PMM88 ausweichen (sofern sich später wirklich herausstellt, dass iOS nicht nachkommt. Bisher weiß ich von keinem Test, der dies belegt, auch wenn es plausibel klingt, dass das iPad begrenze Kapazitäten hat.). Alle anderen können einfach (m)eine App nutzen.

So wünschenswert eine hohe Rechenleistung, das Mergen von ~16 Ports, eine tolle grafische Oberfläche und beliebig viele Splitzonen auch sind...vielleicht ist es ganz gut, daß das iPad hier eine Hardware und damit eine Limitierung vorgibt, sonst würde man ja bei der Entwicklung so einer App nie zu Ende kommen.

Genau das denke ich auch!

Ach ja, ein lang gehegter Wunsch von mir wären Splitzonen, die mit den Händen mitwandern.

Daran denke ich auch schon lange, ich nenne es "Dynamic Split Note", also ein dynamischer Split-Punkt. Nur war mir nicht klar, wie ich sowas anbieten könnte. Keyboards kann man ja nicht umprogrammieren... Höchstens als VST. Und dann ist mir das iPad und seine Midi-Möglichkeiten unter gekommen, und dann bin ich letztens auf die Idee von iMIDIPatchbay gekommen. Irgendwann will ich da so eine Funktion dann auch implementieren. Schaun wir mal :)

Mainstage kann das??

Viele Grüße,
Johannes
 
... gäbe es aktuell ein Hardware-Produkt, mit dem das ginge, dann würde ich dazu die Software schreiben. Nur gibts das leider nicht und ich werde mich in naher Zukunft auch nicht der Aufgabe stellen, so eines auf den Markt zu bringen. Wenn dies jemand anderes tut, dann mache ich die GUI :) Solange es das nicht gibt, müssen die Leute, die wirklich so eine hohe Anforderung haben, auf ein PMM88 ausweichen (sofern sich später wirklich herausstellt, dass iOS nicht nachkommt. Bisher weiß ich von keinem Test, der dies belegt, auch wenn es plausibel klingt, dass das iPad begrenze Kapazitäten hat.). Alle anderen können einfach (m)eine App nutzen....
imho klingt es überhaupt nicht plausibel, dass ein iPad 'begrenzte' Kapazitäten hat.
Was steckt denn in den alten Schachteln an Prozessoren ? ;)

Das Problem liegt (vermutlich) teilweise darin, dass Midi eine ziehmlich triviale Logik und Bit-Schieberei ist.
In Maschinensprache lässt sich das effizient umsetzen, in den heutigen grafischen Entwicklungs-Umgebungen wird es offenbar vernachlässigt. Bzw es fehlt inzwischen die Erfahrung dafür...
Ein anderes Teilproblem dürfte die Geschwindigkeitsdifferenz zwischen der Midi Peripherie und der 'Zentrale' (iPad) liegen.
Zumindest verstehe ich es so, dass Core Midi per Netzwerk mit sehr viel höherer Datenrate umgesetzt wird, als das Endgerät kann.
Die Pufferverwaltung stell ich mir nicht einfach vor.

Müsste ich so ein Gerät realisieren, würde ich den 'Prozessor' auf jeden Fall auf FPGA-Basis mit WLAN-Schnittstelle planen.
Ist vielleicht mal einen Seitenblick wert. Da gibt's inzwischen klasse Toolkits, die auch erschwinglich sind.
Mit den 'unbezahlbaren' gehen Sachen, wo mir einfach nur die Kinnlade unten bleibt. :eek: :D

allerdings ist der Markt durch die Fokussierung auf Lösungen, die innerhalb eines Rechners (oder Netzwerks) von Programm zu Programm kommunizieren können deutlich reduziert.

cheers, Tom
 
  • Gefällt mir
Reaktionen: 2 Benutzer
imho klingt es überhaupt nicht plausibel, dass ein iPad 'begrenzte' Kapazitäten hat.
Was steckt denn in den alten Schachteln an Prozessoren ? ;)

Die ich von innen kenne: 8bitter.
PMM-88: 6502
AMT8/Unitor8: 8051
MIDIbay: Z80
Akai ME-30P/80P: NEC 78xx (MCU), also auch Z80
Aaaber: die haben pro Port einen UART mit dickem FIFO, zumindest die Emagics (da sind 2 4fach-16550 drin), in der MIDIbay stecken 6850er. Da kann man wirklich parallel prozessieren, bei einer USB-Schnittstele geht halt alles über einen einzigen UART.

Das Problem liegt (vermutlich) teilweise darin, dass Midi eine ziehmlich triviale Logik und Bit-Schieberei ist.
In Maschinensprache lässt sich das effizient umsetzen, in den heutigen grafischen Entwicklungs-Umgebungen wird es offenbar vernachlässigt. Bzw es fehlt inzwischen die Erfahrung dafür...

Genau das, aber der Knackpunkt ist die in Multitasking-Umgebungen nicht wirklich steuerbare Priorität eines entsprechenden Prozesses. Etwas, was man mit Hardware ja problemlos machen kann, weil man da ja sein eigener Herr ist - oder auf darauf optimierte Umgebungen wie MIOS zurückgreifen kann.

Ein anderes Teilproblem dürfte die Geschwindigkeitsdifferenz zwischen der Midi Peripherie und der 'Zentrale' (iPad) liegen.
Zumindest verstehe ich es so, dass Core Midi per Netzwerk mit sehr viel höherer Datenrate umgesetzt wird, als das Endgerät kann.
Die Pufferverwaltung stell ich mir nicht einfach vor.

Genau das ist eins der Kernprobleme. MIDI über USB2 kann in USB2-Geschwindigkeit gesendet werden, MIDI über DIN-Buchsen dagegen nur in seiner klassischen Geschwindigkeit. Um Bei Multiportinterfaces eine gleichzeitige Ausgabe der Daten an alle Ports zu ermöglichen, wurde ja das MIDI Timestamping entwickelt, welches mal MTS oder auch LTS bzw AMT heißt, je nach Hersteller. Und die Pufferung ist da wirklich eine Wissenschaft für sich, gilt es doch einige Sachen zu beachten, siehe meine entsprechenden Beiträge dazu.


Müsste ich so ein Gerät realisieren, würde ich den 'Prozessor' auf jeden Fall auf FPGA-Basis mit WLAN-Schnittstelle planen.
Ist vielleicht mal einen Seitenblick wert. Da gibt's inzwischen klasse Toolkits, die auch erschwinglich sind.
Mit den 'unbezahlbaren' gehen Sachen, wo mir einfach nur die Kinnlade unten bleibt. :eek: :D

FPGA-Boards sind für Hobbyisten schon eine Weile sehr erschwinglich geworden (mit wenigen Ausnahmen), siehe hier. Für Bitgefrickel eigentlich ideal, gerade um aus einem seriellen Bitstrom einzelne auszufiltern.

Wenn ich das Ganze innerhalb einer Kiste selbst rumschubse, habe ich einige Freiheiten. Da hab ich meine UARTs pro Port, die mir Wandlung und Pufferung erstmal abnehmen, ich kann bitfrickeln und auch verzögerungsfrei wieder ausgeben. Wenn der eigentliche Prozessor aber an einer seriellen Nabelschnur hängt, auch wenns eine im Vergleich zu MIDI so schnelle ist wie USB2, habe ich faktisch immer Latenzen.
 
Genau so, wie es klingt :) Man erstellt eine Zone und setzt einen variablen Splitpunkt. Sobald ich dann innerhalb dieser Zone Richtung Zonen-Ende spiele, versetzt sich der Splitpunkt in eben genau diese Richtung. Das ganze kann man dann natürlich limitieren, damit es nicht ins unendliche geht Hier ein Vid: http://www.youtube.com/watch?v=fQMYfzsWX3g

Sehr schön, sehr cool. Ich bekomme MainStage immer nur als fertiges System on the job hingesetzt und darf nix verändern. Daher kenne ich diese Features nicht.

Bei sowas kommen natürlich spieltechnische Fantasien auf...mal angenommen, man hat zwei Bereiche auf dem iPad-Screen (oder gleich zwei iPads), wo in zwei vertikalen Listen Sounds als Schaltflächen angeordnet sind. Dann könnte man ja quasi einen Sound antippen und "in die rechte Hand nehmen", d.h. alle nachfolgenden Tastendrücke der entsprechenden Hand werden mit dem angewählten Sound gespielt. Man spielt z.B. dann eine Linie abwärts, die von der linken Hand übernommen wird und greift sich währenddessen den nächsten Sound für die rechte Hand vom iPad.

Das wäre zum Improvisieren in der Band und zum intuitiven Anwählen von Sounds Gold wert.

Ich finde sowas extrem spannend, weil hier endlich mal keyboardtypische Spieltechnik entstehen kann bzw. ermöglicht wird, die deutlich anders als pianistische Spieltechnik ist.

Harald
 
Hey Leute,

habe gerade etwas entdeckt:
http://www.plogue.com/

werft da mal einen Blick drauf. Diese Software scheint alles zu können, was man überhaupt erwarten kann. Man kann es sogar als Plugin benutzen und wird mir wahrscheinlich helfen, meine Idee zu realisieren. Ich habe mir die Demo runtergeladen und schonmal rausgefunden, dass sich der MIDI Splitter per MIDI fernsteuern lässt :)
 

Unser weiteres Online-Angebot:
Bassic.de · Deejayforum.de · Sequencer.de · Clavio.de · Guitarworld.de · Recording.de

Musiker-Board Logo
Zurück
Oben