MIDI-Routing und Setlist-Management für iOS

  • Ersteller JohannesD
  • Erstellt am
JohannesD
JohannesD
Registrierter Benutzer
Zuletzt hier
02.04.24
Registriert
07.07.04
Beiträge
366
Kekse
398
Hallo Leute,
die rege Beteiligung im iPad-Thread hat mich dazu motiviert, hier einmal zu posten, woran ich gerade arbeite. (Eigentlich habe ich dies schon getan, leider hat sich wider meiner Erwartungen keiner mehr gemeldet. Ich hatte allerdings auch recht wenige Informationen preisgegeben bzw. diverse Ideen sind mir erst später gekommen, deshalb starte ich hier nun einen neuen Versuch.)

Wie bei einigen anderen hier besteht mein Setup aus mehreren Tastaturen und Klangerzeugern. Da ich in meiner einen Band recht viele Sounds gleichzeitig spielen muss, ist für mich Layern und Splitten essentiell. Ich setze hierfür hauptsächlich mein Motif-Rack ES ein, allerdings kommen Orgel und Klavier von anderen Geräten, die selbst nicht splitten können. Hinzu kommt, dass die Bedienung eines Rack-Gerätes recht umständlich ist, weshalb ich dafür zu Hause einen Editor verwende. Ich wäre allerdings gerne in der Lage, auch in der Probe schnell etwas zusammenzubauen, also beispielsweise Keys mit Strings oder Orgel layern, wobei sich das Expression-Pedal nicht auf das Piano auswirken soll.

Ich habe zeitweise auch einen PC eingesetzt, weil mir hier die MIDI-Möglichkeiten gut gefallen haben, allerdings war auch das in der Probe für mich schlecht zu handhaben und auch von den Abmessungen unhandlich.

Seit längerem schwebt mir also eine Lösung für das iPad und auch andere iOS Geräte vor, bei dem man endlich den ganzen Kram intuitiv und schnell regeln kann. Ich weiß nicht, warum es das nicht schon längst gibt… nun reichts, ich mach's selbst. Hierfür habe ich sowohl ein Nah- sowie ein Fernziel, die ich über Weihnachten konkreter ausgearbeitet habe.

Zunächst möchte ich ein MIDI-Patchbay entwickeln, das sowohl die Eingabegeräte, nämlich Tastaturen, Pedale und Controller, sowie die Klangerzeuger anzeigt. Es können dann sehr einfach Zones erstellt und den Klangerzeugern zugeordnet werden. Über Modifikationen sind dann Sachen möglich wie Transponieren oder Umwandeln von Controller-Daten in Sys-EX. Alles wird vernünftig und übersichtlich dargestellt, damit man sofort weiß, welche Zone und welche Controller womit verbunden sind.

Hier einmal ein Screenshot:

GUI1.png

Die Connections werden übrigens nicht erstellt durch Verbinden mit dem Finger, was zu viel Friemelkram wäre. Stattdessen wird ein Fenster eingeblendet, wenn man auf Insert Sound drückt. Bei den Klangerzeugern wird noch angegeben, auf welchen Speicherplatz sie beim Aufruf eingestellt werden müssen. Das Ganze kann dann als Song abgespeichert und in einer Setlist verwaltet werden.

Soviel zum Routing und Setlists. Das zweite Hauptproblem, das ich sehe, ist das Ändern von Parametern, vor allem die Lautstärke der einzelnen Sounds. Hierbei ist es mir weitgehend egal, von welchem Klangerzeuger die jeweiligen Sounds kommen, wenn das Piano zu leise ist, muss es lauter… Deshalb gibt es den Mixer-View, bei dem alle Sounds nebeneinander als Mixer-Strip dargestellt werden. Damit man weiß, wo der jeweilige Sound gespielt wird, ist unten wieder die Zuordnung zu den Tastaturen zu sehen:

GUI2.jpg

Ok, soviel zur grafischen Darstellung. Kommen wir zu Bedienung. Ich möchte ein Hauptaugenmerk auf die schnelle Benutzung legen, da ich viel spontan an den Keyboards mache. Generell sollen zwar alle Regler per Touch verwendet werden können, es soll aber auch möglich sein, Hardware-Controller zuzuordnen. Und da stelle ich mir zwei Sachen vor: Man wird wahrscheinlich nicht so viele Regler haben, wie im Mixer-View angezeigt werden. Deshalb soll es zum einen so laufen, dass man den Regler in der App nur gedrückt hält bzw. auswählt, und dann an einem definierten Hardware-Regler dreht. Der Software-Regler wird dann auf den Wert des Hardware-Reglers gesetzt, aber erst, wenn dieser den Wert des Software-Reglers erreicht hat. Damit entstehen keine Sprünge, das Verhalten kennt man von Yamaha.

Eine andere Möglichkeit soll sein, dass man sich ein paar Hardware-Regler für sagen wir Lautstärke und EQ reserviert, diese aber immer nur Auswirkung auf die Sounds haben, die gerade gespielt werden. Wenn ich die Lautstärke von einem Sound anpasse, dann spiele ich ihn ja in der Regel auch gerade, weshalb ich ein erneutes Heraussuchen des richtigen Reglers eigentlich überflüssig finde von der Usability her gesehen. Bei gelayerten Sounds werden diese gleichzeitig, aber bei Erhalt des Verhältnisses geregelt. Um das Verhältnis hingegen zu manipulieren, greift man auf die erste Methode zurück.

Das Erstellen von Zones funktioniert natürlich auch über Drücken der obersten und untersten Taste.

Das ist das Nahziel.

Beim Fernziel würde ich mich gerne damit befassen, wie man alle Sounds, die im ganzen Setup auf den verschiedenen Geräten vorhanden sind, zentral auswählen kann. Wenn ich also Strings brauche und mehrere Geräte das anbieten, dann möchte ich in der Kategorie "Strings" alle zusammen aufgelistet bekommen und durchprobieren können. Ich möchte mir dann auch keine Gedanken mehr machen, auf den Geräten ein Program (beim Motif heißt es Multi) zu erstellen, das den richtigen Sound auf dem richtigen MIDI Channel spielt. Das soll automatisch gehen, erfordert aber, dass in die App entsprechende Dateien geladen werden, die die nötigen Informationen zur Verfügung stellen. Ist also mit mehr Aufwand verbunden.

Im Moment bin ich mit ein paar technischen Tests beschäftigt, die die Latenz beim Routing betreffen. Damit das ganze funktioniert, muss man ja bei Keyboards, die sozusagen Tastatur und Klangerzeuger zugleich sind, Local Control auf Off setzten. Die MIDI Daten gehen dann zur App und wieder zurück ins Key. Da mir Latenz immer sofort störend auffällt, ist mir das Thema sehr wichtig. Momentan bin ich bei 6ms bei einem einfachen Routing und bei ca. bei 10ms, wenn ich aus jeder Note einen 7-Klang erzeuge. Ich habe aber noch eine Idee, mit der sich das wahrscheinlich noch verkürzen lässt, unter 4ms wird es aber wohl nicht gehen. Ich teste übrigens mit iConnectMIDI, welches mehrere Ein- und Ausgänge hat und für das Managen von größeren Gears gut geeignet scheint.

Ok. Mich würde interessieren, was ihr so davon haltet. Ich weiß, dass es für mich genau das ist, was mir fehlt. Bevor ich mir allerdings zusätzlich den Aufwand mache, es in den App Store zu stellen, würde ich gerne vorab herausfinden, ob es einigen von euch auch so geht wie mir und die App Abnehmer finden würde. Genauso wäre ich auch an weiteren Ideen interessiert, z.B. lese ich im iPad-Thread die ganze Zeit, dass ihr gerne eure Leadsheets mit dem iPad verwaltet. Das ließe sich natürlich auch wunderbar integrieren.

Also lasst hören, was ihr denkt. :)

Viele Grüße und danke fürs Lesen,
Johannes

P.S. Manche von euch haben vielleicht schon die Website zu dem Projekt gefunden (iMIDIPatchbay.com).
 
Eigenschaft
 
  • Gefällt mir
Reaktionen: 6 Benutzer
Ach, Du bist das selbst, das ist ja fein. Seite war irgendwo verlinkt, weiß nimmer ob hier oder im Nachbarforum. Hatte mich auf der Seite schon über den Spruch mit der PMM-88 gefreut, denn sowas in der Art ist ja durchaus noch gefragt.

Ich kenne neben Deinem Projekt nur noch MidiBridge, habe aber selbst eine PMM-88, bei der mir allerdings die Fernbedienung etwas auf den Sender geht. Kann man ja mit MIDITouch, TouchOSC oder Lemur ändern :)

Wenn Du Dich an der Grundfunktionalität der PMM-88 orientierst bzw deren Nachfolgern, bist Du schonmal gut dabei, denn diese Dinger sind ja auch jetzt noch gefragt. Die Programmierung der alten 88er ist am Gerät selbst aber ein PITA, wenn man das mal mit einer Akai ME-30P/80P vergleicht.

Was auf jeden Fall drinsein sollte ist eine wirkliche Unterstützung von Multiport-Interfaces wie dem ESI M4U XL und M8U XL, sonst macht eine Patchbay ja wenig Sinn. Die sind ja beide Class compliant. Ist aber auch genau das Problem dabei, daß die eben durch den Standardtreiber Latenzen haben.


Darüberhinaus fände ich auch evtl interessant, PMM-88 und die Emagic-Interfaces sozusagen als Controller anzusteuern, die Sysexformate dazu hab ich hier und kann sie Dir geben. Teste auch gerne, weiß nur nicht wie ich sowas aufs Pad bekomme, wenns nicht im Store ist. Betatesterfahrung hab ich aus Sounddiver-Zeiten jedenfalls reichlich :)

Ein Mixersetup sollte auf jeden Fall Mackie Control können, Doku dazu gibts ja im Netz, Link hätte ich auch.

Wenn sich das Ding als Steuerzentrale versteht, sollten auch mehrere Bildschirme möglich sein (mit Reiten/Tabs), um zB auf einem davon ein Mixersetup mit Mackiecontrol gefahren werden kann und auf einem Anderen mit einer Setlist.

Die Frage ist halt auch, in welche Richtung Du da Anpaßmöglichkeiten vorsehen willst, denn dann liefe das ja auf sowas wie TouchMIDI raus und sicher sehr aufwendig.

Die Fallstricke des MIDI Running Status sind Dir ja sicher bekannt, ich hab darüber die Tage einen schönen Text auf einer Seite eines uC-Projektes gefunden, der sowohl das Problem als auch die Lösung recht gut beschreibt.

Zum Thema Latenzen: Hardware-Patchbays bzw Multiport-Interfaces sind so aufgebaut, daß sie pro Strang je einen UART mit dickem FIFO haben und nur das, was bearbeitet werden muß, auch über den Prozessor geht. So sind sowohl die PMM-88 als auch das AMT8 aufgebaut, ebenso die Waldorf MIDIbay. In allen diesen Dingern steckt eine 8Bit-CPU, im PMM-88 sogar eine olle 6502 (die kannte ich mal auswendig). Ein iPad hat das dutzendfache an Rechenleistung dieser CPUs, die dem Ding aber nichts nützt, wenn Du den gesamten (womöglich noch bidirektionalen) Datenstrom über einen einzigen Zugang abhandeln willst - das ist dan wie nur ein Notausgang im Kino bei Feueralarm. Ich denke, Du wirst nicht umhin kommen, da Einschränkungen einzubauen und die Routingfunktionen der externen Hardware zu nutzen. Das iConnect MIDI hat dazu ja eine eigene App, die Steuerung erfolgt aber offenbar über MIDI Sysex, und die Befehle sind auf der Herstellerwebseite in einem pdf aufgelistet.

Eine Kiste wie das AMT8 leistet schon erstaunliches, und man kann sie ja noch kaskadieren, USB ist gar noch 1.1. Das kleinere MT4 dagegen, welches nicht die opulente Hardware eine AMT8 hat, kann man durch an alle Ausgänge gesendete Noten mit Controllerdaten dazwischen zum übelst wackeln bringen, hab ich hier schon gehabt. Daher kann ich nur raten, alles, was nicht "processed" werden muß, aus iOS rauszuhalten, sonst wirds eng, siehe oben.

Was dabei rauskommen kann, wenn es zum Datenstau kommt, habe ich hier mal im ersten Beitrag mit Audiobeispielen dokumentiert:
http://www.sequencer.de/synthesizer/viewtopic.php?f=75&t=61568&hilit=Kühe+melken&start=25

Am krassesten ist das erste MT4-Beispiel. Ich habe allerdings erst später durch Zufall rausgefunden, daß im Gegensatz zu meiner Behauptung weiter unten im Thread sehr wohl Controllerdaten enthalten waren, die mir aber erst beim Anschauen auf dem QY700 angezeigt wurden. Diese stammten vom für die Sequenz genutzen Einspielkeyboard, einem Korg Poly 800. Der sendet in der Originalversion nämlich im Ruhezustand dauern Nullcontrollerdaten, das ist auch nicht abschaltbar. Die Grundeinstellung von Logic, bei einem neuen Track erstmal alles an alle Ausgänge zu senden, führte dann zu genau diesem hörbaren Holpern. Auf solche MIDI-Schweinebacken muß man gefaßt sein. Wenn ich das Ding an meinem Terratec PhaseX24 hatte, schmierte dessen MIDI-Interface jedesmal beim Einschalten ab, erst wenn ich den 800er nach dem Interface einschaltete, lief alles.
So einen Kram muß man ausfiltern können, aber halt möglichst schon in der Hardware des Interfaces. Moderne Multiportinterfaces kann man im Prinzip mit einem AVR oder R8C/M16C pro Kanal bauen und diese dann per seriellem Zweidraht koppeln, dann hat man maximale Prozessfilterleistung. Das aber nur nebenbei.
Falls Du Härtests machen willst, stelle ich Dir das besagte Katastrophen-MIDIfile gerne zur Verfügung. Zu meinen Atarizeiten hab ich weitaus mehr Daten über die Ports geschickt, ohne daß es zu solchen Effekten gekommen wäre - incl der getricksten MIDI-outs auf dem ROMport.

So weit erstmal meine Gedanken dazu. Vielleicht kannst damit ja bissl was anfangen.
 
  • Gefällt mir
Reaktionen: 2 Benutzer
Wird in deinem Midifile der Runningstatus verwendet und wieviele Ticks sind zwischen den Events?
 
Klingt hochinteressant, würde mir aber schon fast ein bisschen zu weit gehen. Solange ich mit Hardware-Synths auf der Bühne stehe, brauche ich am iPAD weniger direkten Zugriff auf die Controller, was wohl eher für die Leute sinnvoller ist, die entweder mit Masterkeyboard und Expandern bzw. VSTis arbeiten. Ich brauche auch weniger ein flexibles Routing für Sustain und Controllerpedal. Die würde ich immer direkt am Gerät anschließen und hab lieber ein Pedal mehr am Start. Ich würde auch nie so umständliche Setups fahren wie: unteres Keyboard spielt Sounds vom oberen und oberes Keyboard spielt Sounds vom unteren. Nur in Ausnahmefällen hole ich mir Sounds extern auf die Tastatur, so dass ich im grunde immer weiß, dass die Sounds, die ich gerade spiele, auch aus dem Keyboard kommen. Will sagen, meine Setups erstelle ich auch grundsätzlich am Keyboard, und nicht am Computer und auch nicht am iPAD.
Früher und auch jetzt noch zu Hause im Home-Setup, wo ich noch Expander im Einsatz habe, nutze ich ein PMM88 für das MIDI-Routing, und dort wo es möglich ist, das Umschalten der Programme. Live suche ich demnächst auch wieder nach einer Möglichkeit, weil ich ein Keyboard durch einen Expander ersetzen will. Den soll dann hauptsächlich das Nord Stage ansteuern, der nur eingeschränkte Masterkeyboard-Funktionen hat. Desweiteren setze ich ein Roland AX Remote Keyboard ein, wo ich im Moment weniger MIDI Routing-Probleme habe, weil ich es kontinuierlich direkt an einem Keyboard im MIDI In stecken habe, aber die Anwahl der Programme wäre schön, wenn dies ein Programm übernehmen könnte.
Ich suche also demnächst nach einer Lösung, wie ich mit dem iPAD und einer passenden MIDI Patchbay in erster Linie das Umschalten der Programme des PC3, des Nord Stage des Expanders (vermutlich ein Roland JV2080) vornehme, sowie möglicherweise den Expander mal vom Nord Stage, mal vom PC3 oder auch mal vom AX anzusteuern, vom AX auf Sounds des PC3 oder des Nord Stage zuzugreifen. Was ich nicht brauche, ist eine die Zuweisung von Controllern oder Splitzonen, das mache ich nachwievor an den Keyboards direkt. Ich hab noch nicht so viel Erfahrung mit der Nutzung der External Section des Nord Stage. Möglicherweise ist dies mit einer MIDI Patchbay einfacher und sinnvoller. Ich lass mich da gerne überzeugen.
Was eine PMM88 nicht kann, ist z.B. bei meinem Kurzweil von Programm 158 auf Setup 231 umzuschalten. Wenn ich schon eine zentrale Steuereinheit in's Spiel bringe, sollte die das auch können. Ein Grund, warum die PMM88 aus meinem Live-Setup wieder rausgeflogen ist.
 
  • Gefällt mir
Reaktionen: 2 Benutzer
Sehr cooles Projekt!
Ich glaube, ich habe hier schon mal geschrieben, dass ich an was ähnlichem arbeite. Allerdings mehr Hardware-basiert. Im Konkretem: ein 19" Gerät mit 8 x MIDI In/Out, 4 x Pedal Anschluß, USB für die Steuerung und ev. MIDI In/Out für die Steuerung. Die Idee ist, einen MIDI Switch/Controller/Processor in Hardware zu implementieren. Wenn man "will", kann man dann seine Setups und Einstellungen eben mit dem iPad (über MIDI) vornehmen. Der iPad ist nur als Frontend gedacht und die Latenz ist unwichtig, weil alles im Gerät selber passiert...
Wie auch immer, die Ganze Sache ist gerade aufs Eis gelegt, weil ich mir überhaupt nicht sicher bin, wie viele Teile ich davon verkaufen könnte. Für 100,- ist es sehr schwer zu realisieren, für 200,- vielleicht, wenn man 100 Abnehmer findet.

Nun zurück:
ich denke 49,- Euro sind einfach zu hoch gegriffen für die Funktionalität (und Aufmachung). Mir ist schon klar, dass Du nicht umsonst alles machen möchtest ;-) Aber im Prinzip ist es doch so -- egal wie du es drehst, richtig Geld kann man damit erst verdienen, wenn du 1000de Downloads hast. Die Leute, die so etwas einfach ausprobieren wollen, werden abgeschreckt.
Die Idee ist nicht neu und trotzdem wundere ich mich auch immer wieder, wieso keiner soetwas schon gemacht hat ;-) Ich wünsche Dir viel Erfolg mit Deinem Vorhaben!
 
  • Gefällt mir
Reaktionen: 2 Benutzer
Bevor ich so ein Monsterprojekt starten würde, ist es wichtig, abzuchecken, ob es da überhaupt Bedarf gibt.

Ich kann nur für mich reden, dass ich sowas nicht bräuchte. Momentan nutze ich lediglich ein Keyboard, das wird aber in naher Zukunft auf zwei, eher drei anwachsen. Da ich jedoch die Sounds dann aus dem Rechner hole und Brainspawn Forte nutze, erledigen sich viele Dinge.
Noten lassen sich natürlich anzeigen und das "Zonen"-Problem kann man über MIDI Kanäle lösen. z.B. geht das Instrument, welches auf MIDI Kanal 1 empfängt nur bis E-1, auf MIDI Kanal 2 alles darüber, etc. So arbeitet man zwar mit festen Zonen, hat mich aber bei Nord nie gestört. Ich muss noch in Erfahrung bringen, ob diese MIDI Routings auch fernsteuerbar sind. Falls ja, ist das für mich auf jedenfall eine Lösung.
 
Wird in deinem Midifile der Runningstatus verwendet und wieviele Ticks sind zwischen den Events?

So gut wie keine, habs gerade nochmal angeschaut.

Sieht so aus (Ausschnitt):

14:02:14.413 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.424 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.425 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.425 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.426 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.427 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.427 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.428 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.428 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.429 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.430 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.433 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.433 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.433 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.434 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.439 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.440 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.440 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.440 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.442 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.442 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.442 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.444 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.447 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.448 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.448 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.449 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.449 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.449 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.449 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.450 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.451 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.451 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.456 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.458 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.458 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.459 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.459 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.460 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.460 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.461 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.461 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.462 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.463 To Port 1 Note On 1 C1 64
14:02:14.463 To Port 1 Note On 2 A1 64
14:02:14.464 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.466 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.467 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.468 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.469 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.470 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.471 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.471 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.472 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.472 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.472 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.472 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.474 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.475 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.479 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.481 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.482 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.482 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.488 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.489 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.490 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.491 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.493 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.494 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.497 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.499 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.503 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.504 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.505 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.506 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.514 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.515 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.515 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.516 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.517 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.518 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.520 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.522 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.522 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.522 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.524 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.525 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.529 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.530 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.530 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.530 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.530 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.532 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.534 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.534 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.534 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.534 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.535 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.535 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.539 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.542 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.542 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.543 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.547 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.548 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.548 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.549 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.551 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.552 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.552 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.553 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.553 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.553 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.554 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.554 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.557 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.559 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.560 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.560 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.561 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.561 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.562 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.564 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.565 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.565 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.569 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.571 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.573 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.574 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.575 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.576 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.576 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.577 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.577 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.578 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.580 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.581 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.582 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.582 To Port 1 Control 2 Breath Control (coarse) 0
14:02:14.584 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.585 To Port 1 Control 1 Breath Control (coarse) 0
14:02:14.585 To Port 1 Control 2 Modulation Wheel (coarse) 0
14:02:14.587 To Port 1 Control 1 Modulation Wheel (coarse) 0
14:02:14.587 To Port 1 Note Off 1 C1 64


Kein Runningstatus, sondern Noteoffs. Die Noten sind da so vereinzelt zwischen dem ganzen ControllerSPAM drin, der Poly800 ist halt wie ein Kohlekraftwerk, der darf nicht ohne Filter ins Netz ...

Cubase essential hat ja in der Grundeinstellung erstmal keinen Port ausgewählt, Logic 6 dagegen die Stanardeinstellung "alle", was bei solchen Datenmengen fatal ist. Ich gehöre ja schon MIDI-mäßig zu den alten Hasen, aber daß ein Synth so einen Datenmüll baut, hatte ich auch noch nie, ist ja schlimmer wie ActiveSensing.

@kest: interessante Sache, auf welcher uC-Basis hast Du aufgebaut? Du bestätigst mir ja letztlich das, was ich oben schon schrieb, daß nur das Nötigste über die Software laufen sollte und der Rest von der Hardware erledigt wird. Reine MIDI-Patchbays sind ja leider völlig ausgestorben.

@Dr_Rollo: Warum kann die PMM88 diesen Programchange nicht senden? Weil er aus 2 Teilen besteht? Hab mich mit diesem Teil der PMM noch nicht im Detail befaßt, kommt sicher noch.
 
@microbug:
Ich habe noch nichts gebaut -- nur Schaltpläne gemacht und die Spezifikation geschrieben. Als Basis habe ich ein FPGA. Da drin sind dann 32-Bit Prozessor + UARTs und sonstiges. Ich überlege alles offen zu legen und die Hardware zu Selbstkosten-preis zu verkaufen, in der Hoffnung, dass viele andere dafür was entwickeln.
Die MIDI-Matrix ist eigentlich nur ein Teil des Projektes. Es soll eine universelle "Box" werden, mit MIDI/AUDIO Schnittstellen. Die Software (FPGA Design und die Firmware) kann dann z.B. von der SD-Karte oder über USB geladen werden. Mal ist es dann MIDI Matrix, mal ist es ein Audio-Looper, mal ist es Audio Effekt Gerät. Ist aber, wie gesagt, erstmal zurück gestellt, weil ein Kollege von mir wenig Zeit dafür hat (alles kann ich auch nicht machen ;-))
 
  • Gefällt mir
Reaktionen: 2 Benutzer
@Dr_Rollo: Warum kann die PMM88 diesen Programchange nicht senden? Weil er aus 2 Teilen besteht? Hab mich mit diesem Teil der PMM noch nicht im Detail befaßt, kommt sicher noch.
Ich weiß nicht was Du mit den zwei Teilen meinst, vermutlich Teil A: Umschalten von Programm auf Setup, bzw. Single auf Combi oder von Programm auf Performance (je nachdem wie es beim Hersteller heißt), dann womöglich noch einen Bank Select und dann den ProgramChange. War das was mit MSB/LSB? Ging mir zu tief, und war ich bisher noch nicht müßig genug, mich da einzulesen. Alles was sich im Programmbereich 1-128 bewegte, hab ich auch schon mal mit dem PMM umgeschaltet, geht also ganz gut bei Roland. Bei Korg wird's schon wieder schwierig und bei Kurzweil hört's halt relativ früh auf. Also hab ich bisher meistens auf Programmchanges über die PMM komplett verzichtet, sondern nur das Routing gemacht, was natürlich nicht wirklich effizient ist.
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.
 
Hi, danke für die Antworten....

Ach, Du bist das selbst, das ist ja fein. Seite war irgendwo verlinkt, weiß nimmer ob hier oder im Nachbarforum. Hatte mich auf der Seite schon über den Spruch mit der PMM-88 gefreut, denn sowas in der Art ist ja durchaus noch gefragt.

Ja ich bin es :) Hatte schonmal einen Thread namens "MIDI-Prozessor mit Song-Verwaltung (wie Brainspawn Forte) als Hardware oder iPad-App" im "Masterkeyoards & Controller" gestartet, als ich nach einer fertigen Lösung gesucht habe. Ich habe halt das Gefühl, dass relativ viele so ein MIDI-Patchbay suchen, ohne dass es was Vernünftiges gibt. Ich würde allerdings gerne herausfinden, wie viele es wirklich sind und was dann die konkreten Anforderungen wären.

Was auf jeden Fall drinsein sollte ist eine wirkliche Unterstützung von Multiport-Interfaces wie dem ESI M4U XL und M8U XL, sonst macht eine Patchbay ja wenig Sinn.

Multiport muss wirklich sein, wobei es teilweise natürlich auch möglich wäre, die MIDI-Signale vorher irgendwie zu Mergen, sodass man am iPad nur noch einen Port braucht, aber evtl. reichen dafür dann die Midi-Kanäle nicht und ich selbst möchte natürlich auch lieber alles in einem Gerät haben.

Ist aber auch genau das Problem dabei, daß die eben durch den Standardtreiber Latenzen haben.

Für eine geringe Latenz habe ich mir extra iMIDIPatchbay gekauft, das sehr schnell ist. Ich habe aber im Moment keinen Vergleich mit anderen Interfaces am iPad. Generell könnte man die App auch offiziell nur für ein bestimmtes Interface supporten oder explizit drauf hinweisen, mit welchem Interface die versprochenen Latenzzeiten erreichbar sind. Bei iMIDIPatchbay ist vielleicht das Problem, dass es nur 2 ins und 2 outs hat, aber per USB kann man bis zu 8 Geräte anschließen. Mir reicht das.

Darüberhinaus fände ich auch evtl interessant, PMM-88 und die Emagic-Interfaces sozusagen als Controller anzusteuern, die Sysexformate dazu hab ich hier und kann sie Dir geben.

Ich selbst habe kein PMM-88, weil ich keine Lust habe, mir so ein altes Teil zu holen und dann auch erstmal programmieren zu müssen, damit ich es bequem vom iPad bedienen kann. Meine App soll wirklich ein Ersatz für die alte Hardware sein.

Teste auch gerne, weiß nur nicht wie ich sowas aufs Pad bekomme, wenns nicht im Store ist. Betatesterfahrung hab ich aus Sounddiver-Zeiten jedenfalls reichlich :)

Das ist schonmal gut zu wissen.

Ein Mixersetup sollte auf jeden Fall Mackie Control können, Doku dazu gibts ja im Netz, Link hätte ich auch.

Da müsste man denke ich erstmal sehen, wie viele live etwas verwenden, was auf Mackie Control basiert. Ich habe sowas zum Beispiel nicht.

Wenn sich das Ding als Steuerzentrale versteht, sollten auch mehrere Bildschirme möglich sein (mit Reiten/Tabs), um zB auf einem davon ein Mixersetup mit Mackiecontrol gefahren werden kann und auf einem Anderen mit einer Setlist.

Das verstehe ich nicht ganz. Es gibt ja mehrere Screens. Ich möchte aber lieber mit Multitouch-Geste zwischen ihnen wechseln, damit man nicht genau gucken muss, wo der Tab-Button ist.

Die Frage ist halt auch, in welche Richtung Du da Anpaßmöglichkeiten vorsehen willst, denn dann liefe das ja auf sowas wie TouchMIDI raus und sicher sehr aufwendig.

Soweit soll es erstmal nicht gehen, man muss halt später sehen, wohin es sich entwickelt, wenn überhaupt.

Die Fallstricke des MIDI Running Status sind Dir ja sicher bekannt, ich hab darüber die Tage einen schönen Text auf einer Seite eines uC-Projektes gefunden, der sowohl das Problem als auch die Lösung recht gut beschreibt.

Dann schicke mir den Link doch mal :)

Ich denke, Du wirst nicht umhin kommen, da Einschränkungen einzubauen und die Routingfunktionen der externen Hardware zu nutzen. Das iConnect MIDI hat dazu ja eine eigene App, die Steuerung erfolgt aber offenbar über MIDI Sysex, und die Befehle sind auf der Herstellerwebseite in einem pdf aufgelistet.

Genau, iConnectMIDI direkt anzusteuern wäre eine Möglichkeit, damit sind aber keine Splits möglich. Es wäre aber auch denkbar, dass man die Klangerzeuger direkt ansteuert, sofern sie Splits unterstützen. Das ist zum Beispiel bei meinem Motif der Fall. Wenn viele Daten mit der App verarbeitet werden müssen, muss man sicherlich in diese Richtung gehen. Allerdings bin ich recht sicher, dass für das normale Spielen das iPad problemlos nachkommt. Die Core Midi API bietet Funktionen, mit denen sich Routings einstellen lassen, die dann von iOS gemanaged werden, ohne dass Code der App ausgeführt werden muss.

Wenn irgend ein Gerät zu viel Mist sendet, ist das natürlich ein Problem und man muss weitersehen und vielleicht zu etwas Anderem als einer iPad-Lösung greifen. Für alle Anderen könnte so eine Lösung wie von mir vorgeschlagen aber bestimmt trotzdem sinnvoll sein. Deinen Midi-File probiere ich natürlich trotzdem gerne aus, wenns soweit ist :)

So weit erstmal meine Gedanken dazu. Vielleicht kannst damit ja bissl was anfangen.

Auf jeden Fall danke für die ausführliche Antwort :)


Klingt hochinteressant, würde mir aber schon fast ein bisschen zu weit gehen.

Ok, vielleicht könnte ich ja auch ne kleinere Version anbieten, die nur Geräte umschaltet. Aber dafür gibts glaube ich schon ne App, ich weiß nicht mehr genau, wie die heißt. Ist glaub ich von Yamaha?

Will sagen, meine Setups erstelle ich auch grundsätzlich am Keyboard, und nicht am Computer und auch nicht am iPAD.

Das ist gut zu wissen. Ich liebe mein Nord Piano und meine Korg CX-3, weil da alles direkt erreichbar ist. Hätte ich nur diese Geräte, bräuchte ich auch nicht noch irgend eine App, besonders weil die jeweiligen Tastaturen auch schon genau zu dem Sound passen. Aber das Editieren des Rack-Geräts geht finde ich gar nicht.


Wie auch immer, die Ganze Sache ist gerade aufs Eis gelegt, weil ich mir überhaupt nicht sicher bin, wie viele Teile ich davon verkaufen könnte. Für 100,- ist es sehr schwer zu realisieren, für 200,- vielleicht, wenn man 100 Abnehmer findet.

Also ich würde es wahrscheinlich nehmen, wenn ich damit das machen kann, was ich oben beschrieben habe. :)


ich denke 49,- Euro sind einfach zu hoch gegriffen für die Funktionalität (und Aufmachung).

Was genau meinst du mit Aufmachung? Die Oberfläche der App? Die Website? Wie sollte es nach deinen Vorstellungen aussehen?

Es geht mir nicht darum, richtig Geld zu verdienen. Für diejenigen, die es einfach nur ausprobieren wollen, kann man ja problemlos ne Demo-App machen, bei der ein entscheidendes Feature fehlt. Also daran soll es nicht liegen.


Bevor ich so ein Monsterprojekt starten würde, ist es wichtig, abzuchecken, ob es da überhaupt Bedarf gibt.

Genauso ist es, deshalb poste ich die Idee auch hier, bei mir ist es allerdings so, dass mir mein eigener Bedarf schon ausreicht, um es zu entwickeln. Ich sehe bei der Umsetzung zumindest für mich selbst kein Problem. Sobald man so etwas für die breite Masse, sofern man bei einer Spezialanwendung für Musiker davon sprechen kann, anbietet, ist natürlich viel mehr Aufwand nötig (z.B. wegen solcher Probleme wie die, die microbug oben beschrieben hat, die bei meiner eigenen Verwendung aber gar nicht auftreten).

Ich kann nur für mich reden, dass ich sowas nicht bräuchte. Momentan nutze ich lediglich ein Keyboard, das wird aber in naher Zukunft auf zwei, eher drei anwachsen. Da ich jedoch die Sounds dann aus dem Rechner hole und Brainspawn Forte nutze, erledigen sich viele Dinge.

Ja, sobald ein Rechner im Spiel ist macht die Verwendung so einer App wirklich nicht mehr viel Sinn, obwohl ich sagen muss, dass die MIDI-Verschaltung, wie ich sie mit Forte damals gemacht habe, auch irgendwann recht unübersichtlich wurde. Forte bietet auch kein Übersetzen von CC in SysEX, wie ich es für mein Motif gebraucht hätte.

das "Zonen"-Problem kann man über MIDI Kanäle lösen. z.B. geht das Instrument, welches auf MIDI Kanal 1 empfängt nur bis E-1, auf MIDI Kanal 2 alles darüber, etc. So arbeitet man zwar mit festen Zonen, hat mich aber bei Nord nie gestört.

Das ist auch ne Interessante Lösung. Aber man muss dann natürlich die Geräte entsprechend einstellen.


Mal ist es dann MIDI Matrix, mal ist es ein Audio-Looper, mal ist es Audio Effekt Gerät. Ist aber, wie gesagt, erstmal zurück gestellt, weil ein Kollege von mir wenig Zeit dafür hat (alles kann ich auch nicht machen ;-))

Schade eigentlich :)

Danke für die Antworten, weitere Kommentare sind willkommen.
 
Multiport muss wirklich sein, wobei es teilweise natürlich auch möglich wäre, die MIDI-Signale vorher irgendwie zu Mergen, sodass man am iPad nur noch einen Port braucht, aber evtl. reichen dafür dann die Midi-Kanäle nicht und ich selbst möchte natürlich auch lieber alles in einem Gerät haben.

Das geht halt nicht ohne Hardware.



Ich habe aber im Moment keinen Vergleich mit anderen Interfaces am iPad. Generell könnte man die App auch offiziell nur für ein bestimmtes Interface supporten oder explizit drauf hinweisen, mit welchem Interface die versprochenen Latenzzeiten erreichbar sind. Bei iMIDIPatchbay ist vielleicht das Problem, dass es nur 2 ins und 2 outs hat, aber per USB kann man bis zu 8 Geräte anschließen. Mir reicht das.

Du meinst sicher iConnect MIDI :)
Der Standard sieht derzeit wohl so aus, daß neben CoreMIDI noch der alte MIDI Mobilizer unterstützt wird, der ja ein eigenes Protokoll besitzt. Nur für ein bestimmtes Interface wäre aber Blödsinn, denn die Anzahl der class compliant MIDI Interfaces mit Multiport ist sehr überschaubar. Neben den ESI-Modellen ROM I/O II, MU4XL und MU8XL fällt mir nur noch das iConnect ein, alle Anderen haben eigene Treiber. Das große ESI hat zudem dummerweise keine Patchbayfunktionen, das wäre sonst ideal.


Ich selbst habe kein PMM-88, weil ich keine Lust habe, mir so ein altes Teil zu holen und dann auch erstmal programmieren zu müssen, damit ich es bequem vom iPad bedienen kann.

Och, das ließe sich ja remote machen. So ist zB die Anbindung des ASR-X in Sounddiver entstanden: ich hatte das Gerät und der Entwickler hat den Code angepaßt.

Meine App soll wirklich ein Ersatz für die alte Hardware sein.

Äh - sorry, aber das wird nicht funktionieren, aus den oben geschriebenen Gründen. Du brauchst auf jeden Fall externe Hardware, die die einfachen Routings von der App fernhält, und was liegt da näher, als auch die alte Hardware einfach mit einzubinden, wenn sie doch eh meist schon da ist (und es keine aktuellen Alternativen gibt). PMM-88-Besitzer haben das Problem, daß kein Mensch einen Editor für ein aktuelles OS geschrieben hat, es gibt nur eine Atari-Software aus der ersten Generation mit Grusel-GUI, die unter Emulatoren läuft. Ähnliches gilt für die anderen Patchbays auch, wobei die AMT8 sich per MacOS-Kontrollfeld bedienen läßt. Ich habe hier diverse Patchbays gehabt und deren Verhalten auch analysiert, vor allem weil ich für die große Akai eine Anbindung für Sounddiver gebaut habe.


Da müsste man denke ich erstmal sehen, wie viele live etwas verwenden, was auf Mackie Control basiert. Ich habe sowas zum Beispiel nicht.

Gibt wohl etliche, die die besagten MOTUs genauso einsetzen, gab hier auch mal einen Thread dazu, der mich letztlich auf das 828MKII brachte.


Das verstehe ich nicht ganz. Es gibt ja mehrere Screens. Ich möchte aber lieber mit Multitouch-Geste zwischen ihnen wechseln, damit man nicht genau gucken muss, wo der Tab-Button ist.

Weißnicht , ob das in der Praxis wirklich funktioniert. Denk nur mal an die Multitasking-Fingergesten, die mußte ich gerade wg Animoog abschalten, ist also nicht ganz einfach. Zudem: wenns nur eine feste Anzahl Tabs sind, kann man die nach ner Weile blind bedienen.



Dann schicke mir den Link doch mal :)

Gerne. Ist ein Dokument von Paul Maddox (der mit dem Monowave) und nennt sich "MIDI and the AVR" auf AVRfreaks. net. Google macht Murks mit dem Link, sonst hätte ich den hier reinstellen können, das Dokument wird aber sofort gefunden, ist ein pdf.http://www.avrfreaks.net/index.php?...nm7b-txEQ&sig2=FdlAWoBwPYlSJEVdXlaSdA&cad=rja

Genau, iConnectMIDI direkt anzusteuern wäre eine Möglichkeit, damit sind aber keine Splits möglich.

Genau, sowas mußt Du dann prozessen. CoreMIDI kann das ja, wie Du schon schriebst, ebenso das Mergen.

Deinen Midi-File probiere ich natürlich trotzdem gerne aus, wenns soweit ist :)

Ich warne Dich aber vor, das Ding ist wirklich grausam, Du hast ja den Ausschnitt gesehen.

---------- Post hinzugefügt um 21:39:46 ---------- Letzter Beitrag war um 19:40:15 ----------

Dr_Rollo: Ja, ich meinte das mit MSB/LSB. Eine vernünftige Oberfläche kann beides, sowohl MSB/LSB als auch 16bit-Programmnummern. Ich hab gerade nochmal nachgeschaut, die PMM-88 kann keinen Bankselect senden, also nur PC von 0-127. Reichte zur Zeit ihrer Entwicklung ja völlig aus.
 
Du scheinst es ja ernst zu meinen mit deinen Zweifeln :) Also:

Nur für ein bestimmtes Interface wäre aber Blödsinn, denn die Anzahl der class compliant MIDI Interfaces mit Multiport ist sehr überschaubar.

Sehe ich nicht so. Nur weil sie class compliant sind, heißt es nicht, dass sie alle gleichgute Latenzen zeigen. Bei Audio-Interfaces behauptet ja auch kein VSTi-Hersteller, dass sie mit allen verfügbaren Geräten ohne Kompromisse spielbar sind. Hinzu kommt der Punkt (den du ja auch selbst genannt hast), dass eventuell von iMIDIPatchbay angesteuerte Routing-Features nur auf einigen bzw. einem ganz bestimmten MIDI-Interface (in dem Fall iConnectmidi, die Namen sind wirklich leicht zu verwechseln :) ) verfügbar sind.

Och, das ließe sich ja remote machen. So ist zB die Anbindung des ASR-X in Sounddiver entstanden: ich hatte das Gerät und der Entwickler hat den Code angepaßt.

Der Punkt ist eher, dass ich keine App mache für eine Hardware, die ich selbst nicht verwende. Ich möchte ja etwas entwickeln, was auch mein eigenes Problem löst. :)

Äh - sorry, aber das wird nicht funktionieren, aus den oben geschriebenen Gründen.

Ich weiß nicht, ob wir ein bisschen aneinander vorbeireden, oder ob deine Zweifel wirklich begründet sind. Wenn ja, dann bin ich froh, so früh davon zu erfahren. Ich müsste nochmal wissen, von was für einem Setup du ausgehst, ich hatte leider noch keine Zeit, den von dir verlinkten Thread zu lesen. Wenn du mit deinem File ein auf dem Markt befindliches Interface in die Knie zwingst, dann handelt es sich vielleicht auch um eine hohe Leistungsforderung, die nicht unbedingt jeder stellt.

Du brauchst auf jeden Fall externe Hardware, die die einfachen Routings von der App fernhält

Ich glaube wirklich, dass du dich sehr eingehend mit dem Thema befasst hast und danke dir für deine Hinweise! Ich habe aber auch meine Tests gemacht und dabei für meine Anwendung nicht feststellen können, dass eine Lösung (zumindest mit dem schnellen iConnectMIDI, wobei jedoch das ganze Routing wie gesagt über iOS läuft) definitiv nicht funktionieren wird. Dass es Fälle gibt, bei denen es nicht reicht, ist natürlich klar, und ich akzeptiere auch, wenn diese bei dir auftreten.

Einfache Routings vom Prozessor fernhalten bringt des weiteren auch nur etwas, wenn viele Daten vorkommen, bei denen dies auch möglich ist. Ich glaube, dass zum Beispiel bei meinen Splits eh alles über den Prozessor gehen muss. Wenn mich nicht alles täuscht, kann man auch bei iConnectMIDI nicht sagen: leite alles von Input 1, Channel1, auf Input 2, Channel 2. Man kann nur nach Typen filtern und zwischen ganzen Inputs/Outputs routen, aber nicht Channel-weise. Oder übersehe ich gerade etwas?

und was liegt da näher, als auch die alte Hardware einfach mit einzubinden, wenn sie doch eh meist schon da ist (und es keine aktuellen Alternativen gibt).

Ich denke nicht, dass die "meist" schon da ist, bei mir zum Beispiel nicht :) Und ich für meinen Fall würde lieber einen zweistelligen Betrag für eine App ausgeben, damit ich etwas Ähnliches mit meinem iPad und einem Interface machen kann, welche ich eh schon habe/für andere Sachen verwenden kann.

PMM-88-Besitzer haben das Problem, daß kein Mensch einen Editor für ein aktuelles OS geschrieben hat

Es wird auch kaum jemand sich die Mühe machen, für ein aussterbendes Gerät eine neue Software zu entwickeln, es sei denn hobbymäßig.


Denk nur mal an die Multitasking-Fingergesten, die mußte ich gerade wg Animoog abschalten

Warum?

Gerne. Ist ein Dokument von Paul Maddox (der mit dem Monowave) und nennt sich "MIDI and the AVR" auf AVRfreaks. net

Danke. Durch die Zitatfunktion wird der Link irgendwie sichtbar. :)

Ich warne Dich aber vor, das Ding ist wirklich grausam, Du hast ja den Ausschnitt gesehen.
Alles klar :)

Eine vernünftige Oberfläche kann beides, sowohl MSB/LSB als auch 16bit Programmnummern.

Gut, dass das hier zur Sprache kommt, daran muss ich dann auch denken.
 
Du scheinst es ja ernst zu meinen mit deinen Zweifeln :) Also:

Ja, ich meine das durchaus Ernst mit meinen Zweifeln, weil ich mit dem ganzen 8Bit-Kram nicht nur aufgewachsen bin, sodern auch viel auf der untersten Ebene, also Assembler und Hardware gemacht habe, später dann die ganzen MIDI-Sysex-Bitfrickeleien. Was ich nicht habe, ist Hochsprachenerfahrung - (BASIC zählt ja nicht), ist nicht meine Welt als Bytefrickler.


Sehe ich nicht so. Nur weil sie class compliant sind, heißt es nicht, dass sie alle gleichgute Latenzen zeigen.

Auf das wollte ich garnicht hinaus, sondern auf den Fakt, daß das Angebot viel zu überschaubar ist, um sich da auf ein bestimmtes Gerät festzulegen, zumal das die Interessentenkreise einschränkt.

Der Punkt ist eher, dass ich keine App mache für eine Hardware, die ich selbst nicht verwende. Ich möchte ja etwas entwickeln, was auch mein eigenes Problem löst. :)

Das wäre dann ja purer Eigenbedarf. Wenn Du eine App öffentlich anbietest, mußt Du damit rechnen, daß entsprechende Wünsche auf Dich zukommen.


Ich weiß nicht, ob wir ein bisschen aneinander vorbeireden, oder ob deine Zweifel wirklich begründet sind. Wenn ja, dann bin ich froh, so früh davon zu erfahren. Ich müsste nochmal wissen, von was für einem Setup du ausgehst, ich hatte leider noch keine Zeit, den von dir verlinkten Thread zu lesen. Wenn du mit deinem File ein auf dem Markt befindliches Interface in die Knie zwingst, dann handelt es sich vielleicht auch um eine hohe Leistungsforderung, die nicht unbedingt jeder stellt.

Dann solltest Du vielleicht den Link mal lesen, nur den Beitrag mit den Audiodateien, und diese anhören. Das ist keineswegs eine hohe Anforderung, sodern ein einziges Instrument, welches über eine Tastatur angesteuert wurde, mit einer absolut minimalen Seuquenz. Das Problem dabei ist die Masse der Controllerdaten, siehe Posting oben, und solche Massen können in jedem Setup vorkommen, egal wie umfangreich es ist.



Wenn mich nicht alles täuscht, kann man auch bei iConnectMIDI nicht sagen: leite alles von Input 1, Channel1, auf Input 2, Channel 2. Man kann nur nach Typen filtern und zwischen ganzen Inputs/Outputs routen, aber nicht Channel-weise. Oder übersehe ich gerade etwas?

Das iConnect kann nicht channelweise routen, das geht nur bei der PMM88. Die anderen Kisten können auch immer nur portweise. Alles, was darüber hinausgeht, muß halt über die App gehen, also auch die von Dir angesprochenen Splits - außer Du hast eine Hardware, die das selbst kann: PMM88.
Das reine portweise routen sollte auf jeden Fall in der Hardware bleiben, wie ich bereits schrieb. Mit Interfaces, die keine Patchbayfunktionen haben wie die ESI-Modelle ist das dann schon wieder ein Problem.


Und ich für meinen Fall würde lieber einen zweistelligen Betrag für eine App ausgeben, damit ich etwas Ähnliches mit meinem iPad und einem Interface machen kann, welche ich eh schon habe/für andere Sachen verwenden kann.

Wenn Du eine App zum Verkauf anbietest, kannst Du nicht von allein Deinen Bedürfnissen ausgehen - es gibt immer Wünsche der Anwender.

Es wird auch kaum jemand sich die Mühe machen, für ein aussterbendes Gerät eine neue Software zu entwickeln, es sei denn hobbymäßig.

Da täuscht Du Dich aber gewaltig. Das AMT8 wird, wie die restliche Emagic-Hardware, schon eine ganze Weile nicht mehr hergestellt, und es gibt sogar 2 aktuelle Softwarepakete dazu. Wenn es nach dieser Ansicht ginge, hätte Rudi Linhard nie den Advanced Memorymoog angefangen, der ja nicht nur aus eine Generalüberholung besteht, sondern auch aus einem kompletten Neuerstellen der Firmware. Die ganzen MIDI-Nachrüstungen für alte Synths oder die Ersatz-Assignerboards für Polysix und Opera6 fallen ebenfalls unter diese Kategorie. im Übrigen werden gerade die Emagic-Interfaces nach wie vor per CoreMIDI-Treiber von Apple unterstützt, auch wenn man sie nicht mehr neu kaufen kann.



Der Synth war ständig verschwnden, weil das iPad mein Gegriffel auf der virtuellen Tastatur falsch interpretierte. Probiers einfach mal aus, bei einem Polysynth auf dem iPad Akkorde greifen und dann über die Tasten zu rutschen, die beim Animoog ja Modulatorfunktionen haben.


Gut, dass das hier zur Sprache kommt, daran muss ich dann auch denken.

Denk aber auch dran, daß die Struktur der Klangbänke in den Geräten sehr unterschiedlich ist. Kurzweil hat quasi ein 14Bit-System mit kontinuierlichen Nummern, andere wie Roland oder auch Yamaha ein Oktalsystem etc. Der entsprechene Dialog dazu bei Soundiver ist da sehr komplex, deckt aber auch eigentlich alle Gegebenheiten damit ab, und es kann nicht schaden, sich da Anregungen zu holen: das Programming manual dazu gibts bei deepsonic.ch auf der Downloadseite.

Ich will Dich hier weder demotivieren oder Dir etwas madig machen, sondern aufzeigen, wo die Fallstricke liegen, die Du wahrscheinlich momentan noch nicht sehen kannst - das kommt dann in der Praxis :)
 
Ja, ich meine das durchaus Ernst mit meinen Zweifeln, weil ich mit dem ganzen 8Bit-Kram nicht nur aufgewachsen bin, sodern auch viel auf der untersten Ebene, also Assembler und Hardware gemacht habe, später dann die ganzen MIDI-Sysex-Bitfrickeleien. Was ich nicht habe, ist Hochsprachenerfahrung - (BASIC zählt ja nicht), ist nicht meine Welt als Bytefrickler.

Ok, bei mir ist es genau anders herum, obwohl ich vor langer Zeit auch Mikrocontroller programmiert habe.

Das wäre dann ja purer Eigenbedarf.

Purer Eigenbedarf wäre es, wenn es kein anderer verwenden kann. Das ist natürlich nicht der Fall, schließlich bin ich bei weitem nicht der einzige Mensch ohne Miditemp.

Dann solltest Du vielleicht den Link mal lesen, nur den Beitrag mit den Audiodateien, und diese anhören. Das ist keineswegs eine hohe Anforderung, sodern ein einziges Instrument, welches über eine Tastatur angesteuert wurde, mit einer absolut minimalen Seuquenz.

Dann weiß ich nicht, worin sich dein Test von meinem unterscheidet. Aber wie gesagt, ich schaue es mir an.

Das reine portweise routen sollte auf jeden Fall in der Hardware bleiben, wie ich bereits schrieb.

Da sind wir einer Meinung. Ich will nur sagen, dass so eine Optimierung nur dann von Nutzen ist, wenn man auch viele Daten hat, die so geroutet werden können. Das wäre ja zum Beispiel der Fall, wenn aus dem Instrument der Sound kommen soll, auf dem man auch spielt (also quasi Local Control=On). Sobald splits im Spiel sind, bringt es schon nichts mehr.

Wenn Du eine App zum Verkauf anbietest, kannst Du nicht von allein Deinen Bedürfnissen ausgehen - es gibt immer Wünsche der Anwender.

Volle Zustimmung. Ich sage nichts dagegen :)

Ich will Dich hier weder demotivieren oder Dir etwas madig machen, sondern aufzeigen, wo die Fallstricke liegen, die Du wahrscheinlich momentan noch nicht sehen kannst - das kommt dann in der Praxis :)

Bei mir kommt es so an: Du sagt, mit einem normalen Prozessorsystem kann man kein MIDI-Patchbay realisieren (verkürzte Darstellung). Dagegen sprechen einfach die ganzen Patchbays für den PC. Dass es Schwierigkeiten bei der Umsetzung geben kann und dass man einiges beachten muss, ist sicherlich richtig und ich bin dankbar, dass du mir hier einige nennst, an die ich unbedingt denken muss.

Wie sehr es nervt, wenn ein MIDI-Device nicht nachkommt, weiß ich, da ich damals mal probiert habe, meine Probleme mit einem Midi Solutions Processor zu lösen. Das lief aber überhaupt nicht.

Ich mache jetzt bald die weiteren Tests, dann werden wir sehen, was mit dem iPAD möglich ist und was nicht.

Viele Grüße,
Johannes
 
Ich verstehe noch nicht so ganz, wie Du die Anbindung der Geräte an's iPAD handhaben willst. So ganz ohne Hardware geht es nicht, und je komplexer das System, umso schwieriger die Verkabelung. Hab ich eine Patchbay, die für jedes Gerät MIDI-Ein- und Ausgänge zur Verfügung stellt, bin ich relativ flexibel und auf der sicheren Seite. Du schreibst:
Für eine geringe Latenz habe ich mir extra iMIDIPatchbay gekauft, das sehr schnell ist. Ich habe aber im Moment keinen Vergleich mit anderen Interfaces am iPad. Generell könnte man die App auch offiziell nur für ein bestimmtes Interface supporten oder explizit drauf hinweisen, mit welchem Interface die versprochenen Latenzzeiten erreichbar sind. Bei iMIDIPatchbay ist vielleicht das Problem, dass es nur 2 ins und 2 outs hat, aber per USB kann man bis zu 8 Geräte anschließen. Mir reicht das.
Ich weiß nicht, ob Latenz wirklich das Hauptproblem ist. Mit den 2 INs und 2 OUTs bist Du sehr schnell eingeschränkt, weil Du schon per THRU verkabeln musst, und nicht mehr jedes einzelne Gerät auf allen 16 Kanälen ansprechen kannst, was bei Nutzung von Performances, Setups oder Songmodes schon sinnvoll wäre. Durch Verkettung über Thru entstehen letztlich auch unnötige Latenzen.
Es muss ja nicht gleich die veraltete PMM88 sein, eine MOTU Micro Lite mit 5 INs/OUTs oder MIDI Express 8 INs/OUTs wie die PMM88 wäre schon ne super Sache.

Aber irgendwo hab ich gelesen, dass Motu (unverständlicherweise) im Moment eh noch Probleme mit der Einbindung in iOS hat, sprich MOTU Geräte wie die verbreitete 828MK oder Ultralite nicht supportet werden.
 
  • Gefällt mir
Reaktionen: 2 Benutzer
Natürlich geht es nicht ohne Hardware, wo habe ich das gesagt? :) Man braucht natürlich ein Interface, dass die MIDI-Daten ins iPad transferiert. Je größer das Interface ist, desto besser. Und wenn das Interface mit iOS kompatibel ist, wird es auch mit der App funktionieren.

iConnectMIDI hat wie gesagt auch die USB-Ports, davon 8 Stück. Wenn man keine USB-Keys hat, dann geht es natürlich nicht.
 
Aber irgendwo hab ich gelesen, dass Motu (unverständlicherweise) im Moment eh noch Probleme mit der Einbindung in iOS hat, sprich MOTU Geräte wie die verbreitete 828MK oder Ultralite nicht supportet werden.

MOTU-Interfaces sind halt nicht Class compliant und brauchen einen eigenen Treiber. Wo hast Du denn gelesen, daß MOTU an einer iOS-Anbindung arbeitet? Wäre ja erfreulich, wenn sie dran arbeiten. Das war aber nicht die Diskussion zwischen Kest und mir mit der Hardware-ID im Nachbarthread, oder?
 
Ich hab nirgends gelesen, dass sie dran arbeiten, ich höre und lese immer nur, dass sie nicht kompatibel zu iOS sind, ja, das habt ihr glaub ich auch im anderen Thread irgendwo erwähnt.
 
Ah, ok, das dachte ich mir. Es ist so: an iOS gehen direkt derzeit nur Class compliant Interfaces, also die den Standardtreiber von CoreMIDI und CoreAudio nutzen, wie am Mac auch. Alles, was einen extra Treiber braucht, kann nicht genutzt werden, außer in der App ist eine Unterstützung drin. Unter diese Kategroie fällt der MIDI Mobilizer von Line6, der ein eigenes Protokoll hat und vor CoreMIDI erschien. Wird daher auch von etlichen Apps noch direkt unterstützt.
Eine Liste dazu gibts auf iosmidi.com
 
So, ich habe weiter getestet. Code ist so gut wie unverändert geblieben, als Input habe ich mich mal wild auf meinen 8 Fadern ausgetobt. Außer einer Latenzzeit von 4 bis stellenweise 8ms kann ich beim besten Willen kein Problem feststellen (als Zeiten vergleiche ich hier die Ankunftszeit des Signals direkt am Port sowie der Ankunftszeit des Signals, nachdem es vom iPad verarbeitet wurde. Es kommt hier also noch die Zeit vom Keyboard zum Interface hinzu.). Nun werde ich mal die iOS-API für das Routing verwenden, und nicht selbstgeschriebenen Code. Mal sehen wie es sich da mit der Latenz verhält.
 

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

Musiker-Board Logo
Zurück
Oben