Hi,
mein Kopf klart gerade etwas auf und da möchte ich doch gleich mal meinen Respekt für deine Ausführungen zum Thema Midi in dem von dir erstellten und gerade zitierten Beitrag ausdrücken.
Sehr schön dargestellt
Danke.
Ein zeitgemässeres, moderneres Protokoll, das vor allem auch das Editing deutlich vereinfachen könnte, wäre durchaus nicht verkehrt.
Wenn man mal bedenkt, was im Bereich Audio Editing in den letzten 15 Jahren passiert ist, wäre eine neue Midi-Implementierung nichts so ganz verkehrtes.
Midi ist ja in vieler Hinsicht recht kompliziert aufgebaut bzw. man muss so oft von hinten durch die Brust ins Auge.
Allein Midi Implementation Charts von Geräten sind einfach dermassen kryptisch und dieses Hexadezimalcodezeugs einfach absolut nicht mehr zeitgemäss.
Es gibt ja auch immer wieder Bestrebungen, das alte Protokoll zumindest zu überarbeiten.
Ich will mal so sagen, versuche mal das TCP/IP - Protokoll mit all seinen Layern zu verstehen, daran saß ich einige Semester dran um ein Netzwerk aufzubauen. Jeder würde daran verzweifeln, wenn es keine vernüftige Treiber dazu gäbe. Und genau hier ist das grundlegende Problem. Keiner weiß wie das TCP-Protokoll funktioniert, aber es funktioniert einfach per Plug&Play. Aber nicht weil das Protokoll so dolle ist, Nein, weil es Treiber und Software gibt, wo ein User auf einfachste Weise seine Konfigurationen durchführen kann. Vielleicht kann sich noch einer daran erinnern, Soundkarten und Netzwerkarte zu jumpern und die dazugehörenden autoexec.bat und config.sys immer und immer wieder neu zu konfigurieren... Oje, waren das Zeiten, aber auch schöne! Und an diesem Level steht auch das Midi-Protokoll und deren unterstützende Software als Frontend.
Alle Klangerzeuger heutzutage konzentrieren sich auf das Erzeugen von Klänge und schicken halt ein Midi-Signal, alle SW-Sequencer machen alles bunter aber nicht unbedingt einfacher. "Steuern soll jemand anderes" Für das TD-10 gab es schon vor 10 Jahren Software (Nein, nicht umsonst) wo ich die komplette Modellierung am PC per Midi in Echtzeit vornehmen zu können. Da sieht man das es geht und wie einfach das für einen User war....
Ich will damit sagen, ein Protokoll egal welches kann noch so alt sein, wenn es nur eine optimiertere userfreundliche Software gäbe. Und man müsste sich nicht mit grundlegenden Themen rumschlagen. Ist schon schlimm genug, wenn man im Hex-Mod konfigurieren muss. (brauch kein Mensch. Es programmiert ja auch keiner mit einer Maschinensprache...) Aber glaub mir es gibt auf einigen Unix-Servern Editoren, die sind über 30 Jahre alt, da schafft man es nur mit Aufwand eine Zeile zwischen den Code einzufügen und einige Leute behaupten heute noch das sei der beste Editor der Welt. :biggrin: Und so ist es sicherlich auch in der Midi-Welt.....
EDITH
Zitat
Hier liegt nämlich IMHO noch der Hund begraben: Ein Trigger-Interface muss halt erst einmal die Triggersignale digitalisieren und in Midi Befehle bzw. CC Controller Daten umwandeln. In diesem Bereich sehe ich noch erhebliches Optimierungspotential.
So ist es... Wobei ich davon überhaupt keine Ahnung habe, wo die physikalischen Grenzen liegen.
Gruß Ruby
4 Sem Midi-Studium ist ganz schön heftig (oje). Bisschen mit Midi habe ich auch zu tun. 
Mit Midi kannst du gleichzeitig 16 Kanäle und Multi-Instrumente mit geringster Latenz (Latenz = Übertragungsweg) verarbeiten. Daher verstehe ich dein Timing-Problem bei nur nur einem Multi-Instrument überhaupt nicht. Wenn es Latenzen gibt, hat das nichts mit dem Midi-Protokoll zu tun, denn der Übertragungsweg ist für alle Protokolle gleich. Es gibt einfache Lösungen wie man vorhandene Midi-Latenzen minimieren kann. Thema 128 Abstufungen; Was hält einem davon ab CC-Werte in Kombination zu verarbeiten? Dafür gibt es ebenfalls schon Beispiele. Somit wären um ein vielfaches an Abstufungen möglich.
