MIDI-Routing und Setlist-Management für iOS

[microbug]

Das waren ja jetzt nur ein paar Controller auf nur einem Kanal und nur einem Port? Zum Warmlaufen ganz gut, aber das ist ja nur der Anfang. Ein App-Streßtest müßte aus einem komplexen Arrangement mit sagen wir mal 16 Spuren, Controllerdaten und MIDIClock bzw MTC bestehen, und es darf weder was wackeln noch unsynchron werden, denn alle Realtime-Messages müssen bevorzugt behandelt und MIDI Systex niemals unterbrochen werden. Dann hast Du nur einen Port, es können aber bis zu 8 sein, und pro Port 16 Kanäle, das ist nicht Ohne. Die Hersteller von Multiport-MIDI-Interfaces wie Emagic und Steinberg (bzw EES, die deren Interfaces herstellte), haben ein eigenes Übertragungsverfahren entwickelt, um im Timing bleiben zu können, bei Emagic nannte sich das "active MIDI Transmission", bei dem die MIDI-Daten schon vorher bzw mit Zeitstempel an die Hardware übertragen werden und die Hardware dann den zeitstempelsensitiven Transfer übernimmt. Ein solches Verfahren hat auch MOTU, ist aber immer nur dann funktionsfähig, wenn man Hard-und Software aus dem gleiche. Hause einsetzt. Logic unterstützt AMT nach wie vor noch mit AMT8 und Unior8, Steinberg ebenfalls das Midex8 mit Cubase und MOTU sowieso. Dieses Verfahren nennt sich bei jedem Anders, das Prinzip ist allerdings immer das Gleiche.
Aus dem Geschriebenen wird auch ersichtlich, daß ein Class-compliant Interface ab einer gewissen Portzahl dabei außen vor steht, weil es diese Übertragungsart nicht beherrscht. Sicher, man kann jetzt einwenden, daß die Emagic-Interfaces alle noch USB 1.1 sind, aber erstens ist auch bei USB2 irgendwann die Grenze erreicht u d zweitens ist der echte MIDI-Port das Nadelöhr, und das muß man berücksichtigen.
Wenn Du nur MIDI als Protokoll über USB fährst, hast Du das Problem nicht bzw an andere Stellen, weil MIDI-USB ja wie Daten in USB-Geschwindigkeit übertragen werden. Sobald Du aber echte MIDI-Schnittstellen dabeihast, muß auf den Unterschied in der Übertragungsgeschwindigkeit Rücksicht genommen bzw eine technische Lösung geschaffen werden, und die heißt sehr oft Hardware mit Zwischenspeicher oder die schon genannte Übertragung mit Zeitstempel.
Ich hatte irgendwo mal im Netz eine Seite gefunden, auf der dieses Verfahren beschrieben wurde, mal sehen ob ich die nochmal finde, dann poste ich auch den Link.
Eine Software, die den Anspruch hat, eine PMM-88 zu ersetzen und zu diesem Preis verkauft werden soll, darf sich in dieser Hinsicht keine Schwächen erlauben, denn Du mußt damit rechnen, daß man Dich beim Wort nimmt und sich Leute mit einem großen Gerätepark sowas zulegen, und wenns dann hinten und vorne wackelt hast Du ein Problem. Willst Du das vermeiden, baue lieber eine Beschränkung ein, die ein Arbeiten mit geringen Latenzen ermöglicht bzw bei der Du das auch halbwegs garantieren kannst und dokumentiere das dann auch. Zb Beschränkung auf eine gewisse Anzahl am Ports. Das nur als Idee.

Warum ich das so ausafühlich schreibe? Ganz einfach: weil Du Dir da ganz schön was vorgenommen hast und ich gerade den Eindruck bekam, daß Du Dir das etwas zu einfach vorstellst - das genau ist es nämlich nicht, daher auch meine entsprechenden Texte von Anfang an, und weil ich die Tücken komplexer Setups noch sehr gut aus der eigene Praxis kenne.
Ein Nachsatz noch zu der Sache mit dem Preis: eine PMM-88 war, ebenso wie ein AMT8 als Neugerät nicht billig, lagen beide so um die 500DM und drüber, aber auch jeden verdammten Pfennig Wert, weil stabil und solide, daher auch heute noch beliebt. Sich daran mit nur einer Software messen zu wollen ist schon ein ziemlicher Anspruch, sei Dir dessen bewußt.

Wenn Du Dir sicher bist, diesem Anspruch genügen zu können, dann gut, wenn Du da Zweifel hast, lieber das ganze eine Nummer kleiner angehen, aber dann auch konsequent. Hat schließlich schon genug halbe Sachen auf dem Markt. Das ist jetzt nicht böse gemeint, sondern ehrlich.

Nachtrag: ich habe die spezielle Seite nich noch nicht entdeckt, aber die Technik nennt sich IIRC MIDI Time Stamping und wird auch bei MOTU z so genannt (MTS). Wenn Du nach diesem Begriff googlest, findest Du einige Seiten bzw. Diskussionen, die auf die Problematik im Detail eingehen, speziell bei Multiport-Interfaces. Es ist wirklich so, was einige schreiben: Logic unter MacOS 9.x mit einem AMT8 (Direktansteuerung ohne OMS) hatte ein besseres Timing als unter OSX, da CoreMIDI nur einer von vielen Hintergrundiensten ohne besondere Priorität ist. Wie das bei iOS aussieht, kann ich da nicht sagen, das weißt Du sicher besser.

 

[JohannesD]

Hi,
ja der Test ist simpel, entspricht aber denke ich schon dem Datenaufkommen, wie es bei mir auftritt. Es ist denke ich egal, ob die Nachrichten auf demselben oder verschiedenen Kanälen kommen, bei den Ports denke ich auch, zumindest, was iOS betrifft.

Jetzt glaube ich, du hast meine Absichten etwas anders verstanden, als ich es meine. In meinem Ausgangspost habe ich beschrieben, wie ich mir den Workflow mit der App vorstelle. Nur darum sollte es hier eigentlich gehen. Es kann gut sein, dass sich mit dem iPad und einem normalen MIDI-Interface nicht dieselbe Leistungsfähigkeit erzielen lässt wie mit einem Gerät, das nur diese eine Aufgabe hat und dafür hochoptimiert ist. Wenn das dein Standpunkt ist, dann hast du vollkommen recht. Vielleicht sollte ich den Text auf der Website dann ändern, damit es hier kein Missverständnis gibt. Ich möchte keine App, die "New PMM-88" heißt" machen und diese auch zu demselben Preis verkaufen. Der Mehrwert der App liegt in der Bedienung, nicht in einer besseren Leistungsfähigkeit für höchste Midi-Anforderungen.

Ich bin nach wie vor überzeugt, dass die Kapazität vom iPad für meine Anwendung ausreicht. Und mein Ziel dieses Threads ist, herauszufinden, ob es noch weitere Leute gibt, die es genauso wie ich anwenden würden. Vorher möchte ich mir eigentlich über keine technischen Eventualitäten Gedanken machen, denn es ist sinnlos, ein Problem zu lösen, das keiner hat.

 

[microbug]

Ich war halt von dem Text auf der Webseite ausgegangen, denn das ist es, was potentielle Interessenten auch sehen, und wer eine PMM-88 (die es auch als PMM-44 mit nur 4x4 Ports gab) kennt, der könnte die gleiche Leistungsfähigkeit erwarten und enttäuscht werden. Insofern wäre es wirklich sinnvoll, den Text dort zu ändern, und letztlich wirst Du aber trotzdem Limitierungen einbauen müssen schätze ich, oder eben Aussagen über die Grenzen des Ganzen treffen.

Wenn jemand sich zB ein iConnect MIDI kauft und da alle verfügbaren Ports nutzt, kanns sehr schnell sehr eng in Deiner App werden, je nach eingestelltem Routing oder Filterungen. Daher würde ich zB beim iConnect MIDI nicht alle 8 möglichen USB-Ports erlauben, sondern nur soviel, wie die App vom Datendurchsatz her verkraften kann. Sicher reicht das Ganze für das, wie Du es für Dich vorhast aus, aber wenn man eine App für Andere anbietet, muß man eben auch an den Worstcase denken - spart ne Menge Ärger. Wird ein iConnect MIDI mit den vorhandenen MIDI-Ports exzessiv genutzt, kann das auch schon eng werden, denn die ganzen Filterungen sind auch nicht ohne, und ohne portweise Filterungen sollte die App jedenfalls nicht sein, denn so MIDI-Datenschleudern wie der besagte Poly800 sind nach wie vor im Einsatz, und nur ein kleiner Teil davon hat das HAWK-Kit drin, mit dem der keinen solchen Datenmüll mehr produziert. Gibt ja auch noch andere Kisten.

Davon unabhängig bleibt die Problematik mit System Realtime und Sysex bestehen, auch bei geringem Datenaufkommen. Die Problematik sollte Dir aber eigentlich nicht neu sein.

Ich werde mal schauen, daß ich ein kleines Multiport-MIDI-Interface in die Finger bekomme, zB das ESI ROM I/O II. Damit werde ich mal CoreMIDI bei iOS auf den Zahn fühlen, natürlich mit dem datenzugemüllten MIDI-File von oben. Das alte ROM I/O jedenfalls war dem nicht gewachsen gewesen.
Das ist aber ein eigenes Thema, zB für den iPad Thread

 

[JohannesD]

Ja, so war der Text nicht gemeint, er sollte nur Leute ansprechen, die nach der Funktionalität des PMM-88 suchen, aber nicht unbedingt nach der Leistungsfähigkeit. Wenn ich dr_rollo richtig verstanden habe, dann hat er den PMM-88 hauptsächlich für das Umschalten der Geräte nutzen wollen. Das ist natürlich mit Kanonen auf Spatzen geschossen, aber es scheint ja offenbar nicht viele andere Möglichkeiten zu geben, sodass man sich bisher ein teures Gerät zulegen musste, obwohl man nur einen kleinen Teil davon nutzt. Genau in so eine Lücke könnte eine App springen.

Wenn eine App verkauft, darf man natürlich keine Versprechen machen, die nicht gehalten werden können. Bin selbstständig im Softwarebereich und weiß das zu gut.

Ich würde sowieso eine kostenlose Version anbieten, mit der man testen kann, ob sie mit dem eigenen Equipment zufriedenstellend funktioniert. Nach dem Prinzip arbeiten ja viele Software-Produkte wie z.b. Forte.

Bin auf deine Tests gespannt, ich lese ja drüben auch.

 

[HaraldS]

Ich habe mal eine MIDI-Routing-Software in Visual C++ geschrieben, ich verwende ein MIDISport 8x8s Interface. Selbst bei voller Auslastung habe ich keine Timingprobleme bekommen, die auf das Interface zurückzuführen wären.

Es wäre natürlich auch gut, alle technischen Eventualitäten und Fallstricke von vornerherein zu berücksichtigen und zu umgehen - aber das wird sowieso nie perfekt funktionieren. Meine eigene Software liegt z.B. wegen des Benutzerinterfaces auf Eis...ein gutes Benutzerinterface zu programmieren, das unter Probenbedingungen schnell und zuverlässig funktioniert ist nicht so einfach.

Zudem habe ich die Erfahrung gemacht, daß JEDER Keyboarder früher oder später sein Setup ändert. Auch dafür ist meine Software (in Grenzen...) vorbereitet, sodaß viel mit Variablen und abstrahierten MIDI-Portnamen gearbeitet wird: grundsätzlich werden Geräte bei ihrer Bezeichnung angesprochen ("Korg N-364"), es wird nicht direkt der Portname ("MIDISport 8x8 MIDI OUT: 1") verwendet. Eben damit die N-364 später auch an einem anderen Port hängen kann, oder langfristig durch ein anderes Gerät ersetzt wird: dann kann man mit Find&Replace in der Setup-Text-Datei alle Strings "N-364" durch das neue Gerät (oder das neue VSTi...) ersetzen lassen. Das Find&Replace ist keine sonderlich elegante Lösung, aber funktioniert.

IMHO müsste so ein Routing-Programm vor allem den Keyboarder unterstützen, der flexibel und trotzdem detailliert seine Geräte programmieren will. Und eben auch unterschiedliche Geräte.

Harald

 

[JohannesD]

IMHO müsste so ein Routing-Programm vor allem den Keyboarder unterstützen, der flexibel und trotzdem detailliert seine Geräte programmieren will. Und eben auch unterschiedliche Geräte.

Genau. Wie findest du denn das Konzept? Könntest du damit was anfangen, oder fehlt dir was, sowohl von den Funktionen als auch von der Oberfläche?

 

[HaraldS]

Genau. Wie findest du denn das Konzept? Könntest du damit was anfangen, oder fehlt dir was, sowohl von den Funktionen als auch von der Oberfläche?

Ich persönlich könnte damit nichts anfangen, weil ich voll auf PCs setze und bisher keinerlei Erfahrungen mit Apple-Geräten habe. Aber alles, was ich auf der Bühne verwende, will ich detailliert unter Kontrolle haben, um im Fehlerfall zumindest einen Ansatzpunkt für die Fehlersuche zu haben. Ausserdem habe ich aktuell keine Band, in der ich ein so großes Setup spiele, dass ich so eine Anwendung bräuchte. Grundsätzlich ist es aber ein gutes Vorhaben. Ich persönlich würde für so eine vernünftige Software auch deutlich mehr als nur 42,- o.ä. zahlen. Zur Oberfläche kann ich leider nichts sagen, ich habe noch nie einen Touchscreen unter den Fingern gehabt, daher kann ich nicht abschätzen, wie gut sowas bedienbar wird.

Was mir bisher fehlt (vielleicht habe ich es überlesen): Initialisierungs- und Reset-Sequenzen, die bei Anwahl bzw. Verlassen eines Routings gesendet werden. Zum Setzen von bestimmten Parametern, die nur für bestimmte Routings gelten. Damit könnte man auch externe Lichtpulte und Mixer (und sowas wie http://www.pneuphoniker.de/ ...akustische MIDI-Instrumente, mit denen ich mal eine Live-Show zu bestreiten hatte) besser steuern, wo bestimmte Szeneneinstellungen gesendet werden müssen. Auch fehlt mir die Möglichkeit, bestimmten MIDI-Ereignissen bestimmte Aktionen zuzuordnen, also z.B. wenn ich ein Glissando spiele, soll am obersten Ton das nächste Routing aufgerufen werden. Sehr sinnvoll wäre ein MusicXML-Support, wo man Notensatzdatein laden kann: beim Erkennen einer bestimmten Stelle im Stück wird das nächste Routing aufgerufen. Das erlaubt Soundumschaltungen zwischen Sechzehntelnoten, die von Hand kaum möglich wären. Ich hatte als Musical-Keyboarder mal mit einem System zu spielen, das dafür programmiert war (Keycomp von Chr.Buskies). Erst dadurch wurden bestimmte Stellen spielbar. Ausserdem sollte idealerweise die gegriffene Tonhöhe von der klingenden unabhängig sein, sodaß z.B. unspielbare Passagen durch chromatisches Spiel möglich werden. Ebenso verschiedene Velocity-Kurven, sodaß die gegriffene von der gesendeten Velocity unabhängig ist.

Ein wichtiger Punkt wäre auch IMHO die Anwahl der Routings: bei meiner Software ging das grundsätzlich auf drei Wegen:
- über die Anwahl eines Sounds an einem der Keyboards. Im Routing konnte eingestellt werden, von welchen Ports bei welchen MSB/LSB/PrCh-Kombinationen das jeweilige Routing aufgerufen wird. Wichtig ist, daß der Port berücksichtigt wird, damit man möglichst viele Routings von den Keyboards aus anwählen kann. Das ist oft die schnellste Methode, weil die Hände ja beim Spielen die Tasten möglichst nicht verlassen sollten
- über die Plus- und Minus-Tasten, die Space-Taste (= "+") oder einen Fußschalter
- über eine numerische Eingabe: ein spezieller MIDI-Schalter (z.B. eine Taste oder ein Fußschalter) setzt das Programm in den Funktionsmodus, solange der Schalter gedrückt bleibt. Dann werden die Tasten c1-e2 als die Zahlen 1-2-3-4-5-6-7-8-9-0 interpretiert. Es wird auf die Eingabe einer dreistelligen Zahl gewartet. Wenn die dritte Zahl eingegeben wurde, wird das zugehörige Routing sofort angewählt

Sinn und Zweck ist, aus einem großen Repertoire möglichst schnell auswählen zu können. Ich hatte mal in einer Galaband zu tun, wo die Auswahl der Titel auf der Bühne innerhalb von Sekunden passierte. Viele Keyboards sind für solche Situationen nicht schnell genug bedienbar, weil sie z.B. bis zu fünf Tastendrücke brauchen, um aus 1000 titelbezogenen Setups das richtige anzuwählen (z.B. wegen Bankwechseln oder einer "Return"-Taste). Letztlich wäre eine Notenanzeige natürlich noch optimal.

Harald

 

[JohannesD]

Ich persönlich könnte damit nichts anfangen, weil ich voll auf PCs setze und bisher keinerlei Erfahrungen mit Apple-Geräten habe.

Ok! Wenn du irgendwann nicht mehr einen Rechner mitnehmen willst und was kleineres suchst, bin ich vielleicht dann ja schon weit genug mit meiner App

Zur Oberfläche kann ich leider nichts sagen, ich habe noch nie einen Touchscreen unter den Fingern gehabt, daher kann ich nicht abschätzen, wie gut sowas bedienbar wird.

Ich teste meine Grafikentwürfe immer auf dem iPad; das sollte kein Problem sein. Im Moment stelle ich mir auch vor, dass man die Connections über einen Dialog hinzufügt, also nicht etwa zwischen den Ports als Linie zeichnen muss. Hier mal ein Screenshot, aber ich bin noch nicht ganz zufrieden damit.

Was mir bisher fehlt (vielleicht habe ich es überlesen): Initialisierungs- und Reset-Sequenzen, die bei Anwahl bzw. Verlassen eines Routings gesendet werden.

Guter Punkt, obwohl ich das selbst meistens nicht brauche, mir würden die Program Changes beim Aufrufen des Songs reichen. Aber für Licht usw. wäre es gut, stimmt.

Auch fehlt mir die Möglichkeit, bestimmten MIDI-Ereignissen bestimmte Aktionen zuzuordnen, also z.B. wenn ich ein Glissando spiele,

Ha geil, an so etwas habe ich auch gedacht, nämlich an das Weiterschalten zum nächsten Song (oder zur nächsten Szene innerhalb desselben Songs), wenn ich einen bestimmten Akkord spiele.

soll am obersten Ton das nächste Routing aufgerufen werden. Sehr sinnvoll wäre ein MusicXML-Support, wo man Notensatzdatein laden kann: beim Erkennen einer bestimmten Stelle im Stück wird das nächste Routing aufgerufen.

Das ist natürlich schon ziemlich advanced

Ausserdem sollte idealerweise die gegriffene Tonhöhe von der klingenden unabhängig sein, sodaß z.B. unspielbare Passagen durch chromatisches Spiel möglich werden. Ebenso verschiedene Velocity-Kurven, sodaß die gegriffene von der gesendeten Velocity unabhängig ist.

Das wäre bei meinem Programmentwurf realisierbar, indem man jede Taste einer eigenen Split-Zone zuweist und diese dann entsprechend transponiert über einen Modifikator. Ist natürlich ein bisschen aufwändig zu machen...

ein spezieller MIDI-Schalter (z.B. eine Taste oder ein Fußschalter) setzt das Programm in den Funktionsmodus, solange der Schalter gedrückt bleibt. Dann werden die Tasten c1-e2 als die Zahlen 1-2-3-4-5-6-7-8-9-0 interpretiert.

Für so eine Bedienung bin ich auch, ich möchte, dass möglichst viel über die Tastatur und die Controller gemacht wird. Ich habe bisher dabei aber nur an die Erstellung der Routings gedacht, da ich dies oft schnell machen muss. Das Auswählen von Programmen kann man natürlich auch so lösen. Guter Hinweis.

Vielen Dank für deinen Beitrag!

 

[Leef]

Sieht wirklich toll aus! Ich denke schon, daß du mit diesem Projekt einige Leute glücklich machen kannst. Besonders beeindruckt bin ich vom Design, das sieht aus "wie geleckt"! Machst du sowas beruflich?

 

[JohannesD]

Danke fürs Kompliment! Ja, ich mache Softwareentwicklung beruflich, bin Mitgründer eines Software-Startups.

 

[HaraldS]

Ok! Wenn du irgendwann nicht mehr einen Rechner mitnehmen willst und was kleineres suchst, bin ich vielleicht dann ja schon weit genug mit meiner App

Danke ja, ich melde mich...

[Initialisierungs-/Reset-Sequenzen] Guter Punkt, obwohl ich das selbst meistens nicht brauche, mir würden die Program Changes beim Aufrufen des Songs reichen. Aber für Licht usw. wäre es gut, stimmt.

Nicht nur für Licht, auch viele Synths brauchen MSB/LSB/PrCh und ähnliches. Z.B. Moduswechsel (Combi-/Prog-/Multimode) beim Triton Rack brauchen einen Sysexstring, dann eine bestimmte Millisekundenanzahl Pause, dann MSB/LSB/PrCh. Mein Programm hat deswegen einen kleinen Sequenzer eingebaut, der beim Aufrufen eines Setups die Initialisierungssequenz sendet und beim Verlassen die Resetsequenz. Genaugenommen (und nicht unwichtig): nicht sofort nach dem Anwählen, sondern wenn ein Setup ca. 50 Millisekunden angewählt bleibt. Sonst wird beim Durchsteppen der Setupliste (was ja auf der Bühne durchaus vorkommen kann) jede einzelne Initialisierungssequenz gesendet. Das ist ja nicht sinnvoll.

[Weiterschalten bei erkannten Stellen in Noten] Das ist natürlich schon ziemlich advanced

Jo, aber wie gesagt schon vor ~8 Jahren eine gängige Technik bei den Musicals, die mit Keycomp arbeiteten (Jekyll und Hyde in Köln, Schöne und das Biest in Oberhausen). Mittlerweile arbeiten sie alle AFAIK mit Brainspawn Forte und MainStage, was genau das nicht kann . Ein Rückschritt, der vermutlich den Produktionsvorgaben geschuldet ist.

Das wäre bei meinem Programmentwurf realisierbar, indem man jede Taste einer eigenen Split-Zone zuweist und diese dann entsprechend transponiert über einen Modifikator. Ist natürlich ein bisschen aufwändig zu machen...

Och, gar nicht so aufwändig...in meinem Programm sind eingehende Werte wie Tastennummern oder Velocitywerte grundsätzlich Zeiger in Tabellen für Wertänderungen bzw. für die zu sendenden Werte. Also hat jede Taste ihren eigenen Transpositionswert. Das ist ein Array t[127], was nicht so aufwändig zu programmieren ist. Standardmässig wird eben ein linear gefülltes Array für die Ausgabewerte verwendet, das bei Bedarf für jedes Setup abänderbar ist. Bestimmte Arrays sind fest eingebaut, um leichter drauf zugreifen zu können: das betrifft vor allem mehrere Velocitykurven.

Ach ja: Controller sollten verfolgt und individuell angezeigt werden können. 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. So kann man Lautstärkeverläufe mit dem Controllerpedal endlich vernünftig spielen, z.B. wenn man mehrere Stringsounds nacheinander innerhalb einer Band oder eines Orchesters spielt, braucht man eine gute und genaue visuelle Lautstärkekontrolle.

Ich hab natürlich gut reden weil ich mich der Herausforderung, so eine Software vorführreif zu entwickeln, momentan nicht stelle...du machst das, und deswegen ziehe ich den Hut: !

Harald

 

[JohannesD]

Mein Programm hat deswegen einen kleinen Sequenzer eingebaut, der beim Aufrufen eines Setups die Initialisierungssequenz sendet und beim Verlassen die Resetsequenz.

Ich denke, sowas werde ich auch einbauen. Damit ist man am flexibelsten, wenn das normale Program Change nicht ausreicht wegen solchen Sachen, die du beschrieben hast. Ich könnte es vielleicht auch gebrauchen, um beim Motif zwischen Voice- und Performance-Mode zu wechseln.

Jo, aber wie gesagt schon vor ~8 Jahren eine gängige Technik bei den Musicals, die mit Keycomp arbeiteten(Jekyll und Hyde in Köln, Schöne und das Biest in Oberhausen).

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

Och, gar nicht so aufwändig...in meinem Programm sind eingehende Werte wie Tastennummern oder Velocitywerte grundsätzlich Zeiger in Tabellen für Wertänderungen bzw. für die zu sendenden Werte.

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.

Controller sollten verfolgt und individuell angezeigt werden können. 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?

So kann man Lautstärkeverläufe mit dem Controllerpedal endlich vernünftig spielen, z.B. wenn man mehrere Stringsounds nacheinander innerhalb einer Band oder eines Orchesters spielt, braucht man eine gute und genaue visuelle Lautstärkekontrolle.

Verstehe ich auch nicht ganz, aber klingt interessant. Schaltest du mit dem EXP-Pedal zwischen verschiedenen Sounds, je nach Position? Und mit er Anzeige würdest du dann sehen, innerhalb welches Sounds du entsprechend bist?

Ich hab natürlich gut reden weil ich mich der Herausforderung, so eine Software vorführreif zu entwickeln, momentan nicht stelle...du machst das, und deswegen ziehe ich den Hut: Anhang anzeigen 203651!

Ich will endlich mit dem iPad solche MIDI-Aufgaben übernehmen, weil es gut zu bedienen und wunderbar leicht ist. Wenn ich an die ganzen Möglichkeiten denke, dann kommen mir auch tausend Ideen. Daraus muss man jetzt erstmal die wichtigsten herausfiltern, denen man sich als erstes zuwendet.

Danke für deine Anregungen.

 

[FantomXR]

Moin,

ich möchte auch noch kurz was anmerken, wo ich nicht weiß, ob das bisher möglich wäre. Ich habe das in meinem ersten Post hier schon kurz angerissen:

Gibt es die Möglichkeit auf Knopfdruck Sounds Zonen zuzuweisen? Ich könnte mir vorstellen, dass man z.B. im iPad eine Map mit dem Akustikpianosound hat und durch drücken auf den entsprechenden Knopf, dem Sound eine Keyboardzone zuweist. Das würde den Workflow doch deutlich beschleunigen. Gerade das Argument gegen iPad und Rechner, nicht schnell genug dahin zu kommen, wo man hin will, als mit Hardware, würde damit entkräftigt werden. So hätte man eine deutliche Konkurrenz gegen Nord, da die Sounds dann z.B. aus dem Rechner kommen und die Vielfalt einfach größer ist. Dennoch wird man nicht aus dem Workflow gerissen.

Eine kleine Skizze siehe Anhang, wie ich mir das vorstellen könnte.

 

[JohannesD]

Hi,
ich kann leider deine Grafik nicht sehen, wird hier nicht angezeigt. Das war du beschreibst ist genau mein Fernziel. Vielleicht kannst du ja nochmal den Teil in meinem ersten Post lesen und dazu diese Grafik anschauen.



Ist es ungefähr das, was du meinst? Meinen Workflow würde es auch unheimlich beschleunigen. Man könnte fast während des Spielens Sounds hinzufügen.

Viele Grüße,
Johannes

 

[JohannesD]

Jetzt sehe ich deine Grafik. Ok, was bei mir noch nicht der Fall wäre ist das Abspeichen von fertigen Zones. Abwr das wäre eigentlich kein Problem und sicherlich auch sinnvoll.

 

[FantomXR]

Das geht schon sehr in die Richtung. Jedoch würd ich dann (zumindest im Proberaum, um Ideen schnell auszuprobieren) mit festgelegten Zonen arbeiten. Die Tasten unten sollten dann immer anzeigen, welche Zone gerade mit welchem Sound aktiv ist. Dann brauch ich genau zwei Tastendrücke, um einen Sound zuzuweisen. Einmal auf den Sound, der zugewiesen werden soll, und einmal auf den jeweiligen Zonen-Button.

Das größte Problem wäre für mich, dass es eine zusätzliche App ist
Wenn man das in Lemur integieren könnte, wäre es für mich pers. angenehmer. Oder wenn es das dann als VST geben würde, welches man in Forte einbindet und per MIDI über einen festen sich nie ändernden MIDI Kanal fernsteuert.

 

[JohannesD]

jojo, schon kapiert

was machst du denn sonst noch so mit Lemur? Benutzt du das iPad richtig als Controller?

 

[FantomXR]

So auf jedenfall die Theorie. Lemur hat eine massive Begrenzung, was in der heutigen Zeit überhaupt nicht geht.
Die Template sind momentan auf 512kB beschränkt. Das reicht niemals, um eine komplexe Map zu erstellen.

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...

 

[JohannesD]

Interessant, was du da machst

was ich noch nicht ganz verstanden habe, ist, was dir sozusagen meine App nicht bieten würde (ich will ja wissen, was andere Keyboarder so benötigen). Du meintest zuerst, du hättest für so etwas keine Verwendung, aber auf der anderen Seite baust du dir etwas zur Soundauswahl und Einstellen für EQ usw. selbst in Lemur. Sowas will ich ja genau anbieten, oder übersehe ich was?

 

[FantomXR]

Nunja, das was du machst, ist quasi "nur" ein Teil von dem, was ich in Lemur mache.
Geplant ist folgendes:

Ich erstelle in Lemur ein Template. Dieses Template hat (nach heutiger Überlegung) drei Seiten.
1.) Level-Control der Main-Outs und der 8 Aux-Wege
2.) FX-Control aller Inputs
3.) Performing Page

Das alles eben in einer App und somit, brauch ich nur einen Tastendruck, um irgendwo hinzukommen. Wenn ich mit mehreren Apps arbeiten würde (was ich tun müsste, um deine zu nutzen), müsste ich mit der Vier-Finger-Wisch-Geste arbeiten. Das ist mir gerade beim Thema Level-Control zu riskant, das sich da nicht irgendwas verschiebt.