MIDI 2.0™ Prototyping angekündigt (NAMM 2019)

[Vast]

An sich sind beim Din-Stecker ja noch zwei Pins frei. Da könnte man ja auch hardwaretechnisch weiterarbeiten.

Aber es scheint ja doch eher ein Protokoll zu sein/werden.
Also so eine Art XG für alle

Trotzdem: Ich mag Midi 1.0

Tempo war bei Midi immer nur ein Problem, wenn man keine anständige Hardware hatte (hat). Es gibt nun mal gute Midipatchbays, da kannst Du ohne Probleme mit spitzen Timing eine ganze menge Geräte ansteuern.
Probleme gab's immer mit den Midi-Thru-Ketten.
Oder in der Verbindung mit einem Rechner - wenn's kein Atari war. Alle reden vom märchenhaften Timing des AtariST - das ist eine lupenreine Midischnittstelle. Aber halt sauber gebaut.
Und imho gibt es zwei hervorragende USB-Midiinterfaces: Steinbergs weissgradnedmehr und Emagic Unitor/AMT8. Proprietär, aber mit der Option Daten vorab zu buffern und zum richtigen Zeitpunkt knackscharf zu verteilen.
Aber Programme haben trotzdem ihre Probleme. Logic hatte Versionen, in denen sich das Programm aufgehängt hat, wenn ich mehrere Midispuren an alle AMT8-Ports geschickt habe.
Aber das ist/war ein Logic-Problem, kein Midi-Problem.

Und wenn ich zwei Midigeräte per Din-Buchse verbinde (was hier tatsächlich noch regelmäßig passiert), merke ich keine Timingprobleme.
Auch nicht, wenn mein MP-44 dazwischenhängt, Events mappt, skaliert, verteilt, modifiziert.
Aber mit manchen USB-Keyboard-Rechner-Verbindungen bemerke ich Timingprobleme. USB-Midi scheint mir sehr viel Potenzial für Hardwareseitigen Pfusch zu haben.

Auflösung wird überschätzt.
1. gibt's NRPN & Co.
2. Kann kein Mensch 128 Abstufungen in seiner Anschlagsstärke spielen. Aber es gibt nach wie vor eine ganze Menge Software (-Libraries), die keine ordentlichen Übergänge zw. Velocity-Layers hinkriegen.

Mein Fazit:
Midi ist verdammt alt, aber immer noch verdammt gut.
Wenn es Probleme gibt, sollte man mal genauer hinschauen. In den seltensten Fällen ist Midi an sich schuld.

Zur MIDI 128- Auflösung stelle ich zwar fest das mir diese Stufung beim Spielen der meisten Instrumente mit Tastatur genügt.

Wenn ich nun aber auf externer Hardware mit einem Drehregler eine Automation in der DAW fahre - z.b. die Lautstärke einer einfachen Sinuskurve - da höre ich leider die 128er -Stufung im Resultat mit meinen Ohren.

Das bedeutet für mich das es mit 128 Stufen ohne Interpolation unter MIDI 1.0 kein sanftes gleiten gibt wie per Drehregler über eine CV Verbindung ( Volt -Spannungs- Steuerung) .

Unter Anderem aus diesem Grund nerven mich so genannte CV-MIDI -Konverter die man benutzen kann wenn man eine Hardware mit CV -Ausgängen in eine DAW einspielt oder von dort ausgibt.

Die DAW Bitwig in seiner neusten Ausgabe 3.0 bietet die Möglichkeit über den analogen Ausgang eines Audio Interface CV Spannung zur Hardware auszugeben und von dort zu empfangen. Das wünsche ich mir auch von meinen DAW's Cubase, Studio One und Cakewalk by Bandlab. Damit nicht genug, die neue "the Grid" kann damit über externe Hardware mit CV Anschlüssen fliessenden "stufenlosen" Sound vom feinsten produzieren.

https://www.factmag.com/2019/01/16/bitwig-studio-3-announced/


Anhang Bitwig 3.0:
Die DAW Bitwig 3.0 gehört derzeit zu meinen Favortien in meinen virtuellen Warenkorb für das neue Jahr. Allerdings ist ReWire nicht implementiert, was mich natürlich als Benutzer von z.B. Cubase heftig ärgert. Man kann zwar über das Schnittstellen -Tool Jack Audio Signale austauschen, aber es soll angeblich Latenzprobleme geben und Synchronisation zwischen den DAW sei schwierig weil Bitwig offenbar Jack Audio nicht in vollem Umfang unterstützt. Derzeit experimentiere ich mit einem neuen Audio Plugin Host mit dem Namen elements von Kushview.net . Damit kann man umfangreichste Aufgaben ausführen, unter Anderem Audio routen und die Synchronisation via MIDI Clock auszuführen. https://kushview.net/products/element/ Das Programm ist noch neu, es kamen bereits in kurzen Abständen neue Features hinzu seit ich es entdeckt habe.

 

[suboptional]

Die DAW Bitwig in seiner neusten Ausgabe 3.0 bietet die Möglichkeit über den analogen Ausgang eines Audio Interface CV Spannung zur Hardware auszugeben und von dort zu empfangen. Das wünsche ich mir auch von meinen DAW's Cubase, Studio One und Cakewalk by Bandlab.

Evtl. als Alternative
http://www.expert-sleepers.co.uk/silentway.html

 

[clemenserwe]

Das bedeutet für mich das es mit 128 Stufen ohne Interpolation unter MIDI 1.0 kein sanftes gleiten gibt wie per Drehregler über eine CV Verbindung ( Volt -Spannungs- Steuerung) .

Wie bereits erwähnt gibt es NRPN's (Kombination von 2 CC's) die bis 14bit auflösen.
Man könnte also ganz einfach über die Kombination CC 39 (als LSB für CC 7) und CC 7 (als MSB) eine 14 Bit-Auflösung für Volume erreichen.
Genau so ist es implementiert.
So stehen 512 Parameter (direkt definiert) mit hochauflösenden Werten zur Verfügung. Ich nicht definierten CC's mal ganz aussen vor gelassen.
Das sollte für jede DAW-Remote reichen.
Aber es macht (fast) keiner ... (DAW-/ Controller-Hersteller) - die Mackie-Control ist eine der wenigen Ausnahmen.
Und warum sollte das mit Midi 2.0 besser werden?

Und dass es mit Midi 1.0 geht, haben Yamaha und Roland mit dem XG-/XS-Standard vorgemacht.

Wenn ich nun aber auf externer Hardware mit einem Drehregler eine Automation in der DAW fahre - z.b. die Lautstärke einer einfachen Sinuskurve - da höre ich leider die 128er -Stufung im Resultat mit meinen Ohren.

Darüber müssen wir nicht diskutieren, das ist bekannt. Allerdings frage ich mich schon, inwiefern das bei einem richtigen Mix im Songkontext eine Rolle spielt.
Aber trotzdem - es würde ja gehen. (Wenn auch imho nur für's gute Gefühl)

aber drück doch mal Aftertouch und deine Midischnittstelle wird regelrecht geflutet.

Aftertouch muss man sich (hardwareseitig) heutzutage leider so vorstellen, wie einen kaputten Kontakt. Ich habe an einem alten Keyboard ein kaputtes Modwheel, da sieht der Datenstrom genauso aus.
Im Zusammenhang mit meinem damaligen Keyboard-Vergleich habe ich verschiedene Tastaturen daraufhin getestet, ob man einen Aftertouch-Wert stabil halten kann. Die Referenz ist mein Kawai K-5000. Bei dem klappt das ziemlich gut. Ich konnte auch bei den getesteten Keyboards einen Wert recht stabil halten.
Bei günstigeren Tastaturen dürfte es so aussehen, wie von Dir beschrieben. Der Regelweg ist meistens extrem klein und man hat keine Rückmeldung. Beim K-5000 hast Du einen längeren Regelweg mit abgestufter Gegenkraft. Das ist wirklich das einzige Keyboard, an dem ich gerne mit Aftertouch spiele, weil es kein Lotteriespiel ist.
Es ist also eher ein spieltechnisches Problem bzw. ein Problem der hardwareseitigen Umsetzung.

Viel schlimmer ist (bei den entsprechenden Geräten) Active Sensing. Das war immer das erste, was ich in Zusammenarbeit mit einem Rechner ausschalten musste.

Und damit sind wir beim Problempotenzial von Midi 2.0:
Wenn die bidirektionale Kommunikation über eine Active Sensing Technologie realisiert wird, ist der Kanal dicht.
Da müsste die Schnittstelle wirklich schneller gemacht werden.

 

[Drumfix]

MIDI 2.0 scheint ein reines Softwareprotokoll zu sein.

Scrollt man auf der Seite runter, sieht man die wesentlichen Änderungen.

https://www.midi.org/articles-old/m...midi-capability-inquiry-midi-ci-specification

 

[synthpark]

MIDI 2.0 scheint ein reines Softwareprotokoll zu sein.

Scrollt man auf der Seite runter, sieht man die wesentlichen Änderungen.

https://www.midi.org/articles-old/m...midi-capability-inquiry-midi-ci-specification

Ja danke für den Hinweis. Hat sich also bewahrheitet, was ich ich gedacht hatte. Ein paar Softies feiern sich ab voller Euphorie, dabei haben die Änderungen wenig Substanz und bringen keine Verbesserung. Die erhöhte Genauigkeit geht ja dann auf Kosten der Geschwindigkeit.

Da braucht es dann eher ein Konsortium außerhalb der Midi Association, die im Alleingang was Neues auf die Beine sellt. Hat ja schon geklappt mit dem Ableton Link.

 

[Paxi]

Es ist also eher ein spieltechnisches Problem bzw. ein Problem der hardwareseitigen Umsetzung.

Viel schlimmer ist (bei den entsprechenden Geräten) Active Sensing. Das war immer das erste, was ich in Zusammenarbeit mit einem Rechner ausschalten musste.

Und damit sind wir beim Problempotenzial von Midi 2.0:
Wenn die bidirektionale Kommunikation über eine Active Sensing Technologie realisiert wird, ist der Kanal dicht.
Da müsste die Schnittstelle wirklich schneller gemacht werden.

Ich lese mich zwar gerade erst ein, aber ich verstehe irgendwie nicht, warum Midi 2.0 ein Schnittstellen Problem haben sollte. Es soll abwärts kompatibel sein, damit ältere Geräte problemlos mit MIDI 1.0 kommunizieren können. Zusätzlich werden Information auf 32bit Ebene für Midi 2.0 fähige Geräte möglich sein, die dann sicherlich auch eine entsprechend belastungsfähige Schnittstelle besitzen. Die ist doch aber heute mit USB 3.1 und auch USB-C bereits gegeben. Oder verstehe ich da was falsch?

 

[engineer]

Da braucht es dann eher ein Konsortium außerhalb der Midi Association, die im Alleingang was Neues auf die Beine sellt.

Tja, aber wer, wenn nicht Hersteller sollten das tun? Ich bin ja damals über die Messe gestapft und habe mehreren Herstellern mein MIDI2000 Entwurf angeboten. http://www.96khz.org/oldpages/limitsofmidi.htm

Einfach als Anregung. Patent- und kostenfrei. Da will aber keiner einsteigen, weil er den Standard sprengen würde. Und jetzt wird das noch viel schwieriger.

Die Thematik mit den schlecht aufgelösten Controllern, die auch hier weiter oben angesprochen wurde, ist aber genau der primäre Grund:

Man braucht mehr Auflösung UND gleichzeitig mehr Tempo - will man Synthesizer so steuern, wie es analogtechnisch möglich ist. Siehe den von mir gelinkten Beitrag meiner Webseite weiter vorn. Ich benutze bei meinen Selbstbau-MIDI-Controllern generell bis zu 4096 Stufen und es hat sich gezeigt, dass man damit dann auch geräteintern interpolieren kann, um auf typische 16 Bit Skalierungen zu kommen, d.h. man baut einen IIR-Filter rein, der auch Dynamik überträgt, wie die Beschleunigung bei der Maus. Das ergibt dann einen wirklichkeitsnahen Effekt beim Scrollen, Blättern und Vorwärtsbewegen und da man meistens nur 2 Regler mit den Händen gleichzeitg bewegt, reichen auch 230kbps der normalen PC-Uart vollkommen aus:

http://www.96khz.org/htm/midicontroller16.htm

Solche Auflösungsoptimierungen werden in industriellen Steuerungen zusammen mit Dreh-Encodern massenhaft eingesetzt, um z.B. lineare, aber auch logarithmische Potis zu emulieren. Das bräuchte man auch im MIDI, hat aber das Problem, generell 14 Bit und mehr zu übertragen, um z.B. einen logarithmischen Wert, der "oben im Flachen" eine höhere Auflösung braucht, sauber abzubilden.

Genau das ist der Vorteil vieler Volumen-, Painng- und sonstiger Regler im Analog-Synthese-Bereich und das wird mit dem neuen Protokoll so bleiben. Zwar kann jeder Controllerhersteller intern beliebig genug werden, wenn er nach der beschriebenen Art filtert und abtastet, aber er kriegt es nicht raus und wenn er es raus kriegt, gibt es draussen keinen, der es empfängt, weil MIDI viel zu lange 7 Bit hatte ...

... 20 Jahre zu lange, nach meinem Empfinden und deshalb verstehen die meisten Geräte auch nicht mehr.

 

[HarrySH]

@engineer:

Würde mich mal interessieren, wie Du eine Standardübertragung, also nur eine Note, von und zu einem alten Synth aus den 80/90ern mit einer weitaus höheren Taktrate als 31,25 kHz durchführen willst. Damit Midi 1.0 erhalten bleibt. Soweit ich mal vermute, sind die alten Geräte alle auf diese Taktfrequenz hardwareseitig festgelegt.

Ich habe auch das AMT8 und angeschlossen ist es über RS232 am PC. Das muss ja auch sein, damit das Interface sehr schnell mit 8 Midischnittstellen versorgt werden kann. Trotzdem laufen die einzelnen Midibuchsen mit dem Standardtakt.

 

[engineer]

Wenn ich nun aber auf externer Hardware mit einem Drehregler eine Automation in der DAW fahre - z.b. die Lautstärke einer einfachen Sinuskurve - da höre ich leider die 128er -Stufung im Resultat mit meinen Ohren.

Eben und wenn man Modulieren möchte, weil man Gitarrenfrequenzen erzeugen will, die spielabhängig sind und die nicht einfach nur pauschal mit einem LFO auf die Stimme wirken, wird es unmöglich. Solche Überlegungen sind indes ja nichts Neues: Der Trautonium-Entwickler Oskar Sala hatte solche Dinge schon vor Augen, als er mal die Möglichkeiten von MIDI taxierte und eine Prognose der Zukunft der elektronischen Musik abgab: Die klare Aussage war damals, dass das derzeitige MIDI zu grob und zu langsam sei, um das virtuose Spiel abzubilden. Das übrigens um das Jahr 1992, also schon 10 Jahre nachdem MIDI so wie heute spezifiziert war.

Die DAW Bitwig in seiner neusten Ausgabe 3.0 bietet die Möglichkeit über den analogen Ausgang eines Audio Interface CV Spannung zur Hardware auszugeben

Das müsste sich eigentlich mit einem Software-Synthesizer emulieren lassen, wenn man ein unendlich langes Rechteck ausgibt, auf dessen Amplitudenwert der MIDI-Controller wirkt. Die Frage ist aber, wie genau sich ein MIDI-Level in der DAW einstellen lässt. Meistens arbeiten die auch mit proprietären 7 Bit oder orientieren sich an den 10Bit, die von manchen Controllern kommen.

Ein 10Bit-Wert ist aber aus Sicht der technischen Signalverarbeitung nicht ausreichend, um einen 16Bit-Wert (und von der Stimmdynamik kann man von 16 ausgehen) flüssig und artefaktfrei zu modulieren. Man bekommt, je nach Änderungsgeschwindigkeit Treppen = Rechteckimpulse in das Signal, dessen Spektrum sich mit dem des Trägers faltet. Eine Drehbewegung eines Potis, so wie es ein Mensch bedient, hat eine Steilheit von ungefähr 180 Grad / Zehntelsekunde, d.h. man moduliert mit 10Hz nahezu 2/3 des Signalpegels. Man kann auch ohne das Theoriewissen dahinter leicht erkennen, was mit einem Basssignal von 100Hz passiert, wenn da Stufen reinkommen. Eine Controlleränderung im unteren Bereich von z.B. 20 auf 21 lässt die Amplitude um 5% springen. Das ist nicht nur klar hörbar, sondern auch musiklisch untauglich, wenn ich damit was machen will, z.B. eine Basstrommel sounddesignen.

Noch ärger ist es bei der Steuerung von Filtern: Die oftmals bei Soundbearbeitung verwendeten IIR-Filter arbeiten z.B. mit Differentialen 2. und 3. Ordnung, was zur Folge hat, dass minimale Parameteränderungen zu massiven Sprüngen im Signal - ja regelrechten Aussetzern - führen. Solche Filterparameter lassen sich nur in Echtzeit ändern, wenn man sie sehr fein, also z.B. mit Promillebereich ändert und eine entsprechende Abtastrate hat, sodass sich die Änderungen auf viele Ausiosamples gleichmässig verteilt, wie es auch analog der Fall wäre.

Davon sind wir aber sehr weit entfernt, wenn wir Controller nur mit 10..20Hz übertragen und dann noch zu grob sind.

Die gleiche Betrachtung wie bei den Filtern kann man auch beim Physical Modelling anstellen, wenn man Materialparameter ändert, z.B. den Druck auf eine Gitarrensaite und die Position, um die Länge zu ändern. Es gibt keine Chance, dort nicht massive Artefakte zu generieren, wenn man nicht in der Größenordnung der Signalfrequenz und Auflösung kommt.

Ich bleibe damit bei meiner Einschätzung, dass das alte und zu lange aufrechterhaltene MIDI-Protokoll mit seinen Einschränkungen die Entwicklung der Klangsynthese massiv behindert hat und wir heute ganz woanders wären, wenn man rechtzeit den Herstellern ein Protokoll angeboten hätte, welches eine Vielzahl von Parametern mit Auflösungen und entsprechender Bandbreite angeboten hätte.

Der Bereich der Videoentwicklung zeigt ja, dass es geht und funktioniert: Die HMDI-Spezifikationen war ihrer Zeit immer voraus. Da wurden Auflösungen, Formate und Kanäle definiert - auch für Audio !!! - die es noch gar nicht gab und für die man auch noch keine HW oder Chips kaufen konnte. Viele Endgeräte können heute noch nicht alle Formate, aber etliche eben doch und einige Hersteller nutzen das, um ihre Systeme voranzutreiben. Stück für Stück ziehen die Hersteller nach, die einen produzieren Quellgeräte, die Formate erzeugen und immer mehr Endgeräte konnen es verarbeiten. Was unser Thema angeht, lässt z.B. die HDMI 2.0 inzwischen bis zu 32 Kanäle Audio mit 48kHz zu, bzw. 8 Kanale mit 192kHz - es gibt aber keinen Synthesizer, der das ausgibt oder erzeugen kann. Jedenfalls keinen, den man im Geschäft kaufen kann.

Was man überwiegend kaufen kann, hat nach wie vor einmal S/PDIF - Ausgang und irgendwo ein MIDI-Trio. So, wie die AWE64 von 1993.

 

[engineer]

@engineer:

Würde mich mal interessieren, wie Du eine Standardübertragung, also nur eine Note, von und zu einem alten Synth aus den 80/90ern mit einer weitaus höheren Taktrate als 31,25 kHz durchführen willst. Damit Midi 1.0 erhalten bleibt. Soweit ich mal vermute, sind die alten Geräte alle auf diese Taktfrequenz hardwareseitig festgelegt.

Ich habe auch das AMT8 und angeschlossen ist es über RS232 am PC. Das muss ja auch sein, damit das Interface sehr schnell mit 8 Midischnittstellen versorgt werden kann. Trotzdem laufen die einzelnen Midibuchsen mit dem Standardtakt.

Die alten Geräte kann man über einen MIDI-Splitter anschließen, wie Du es beschreibst. Über deren Möglichkeiten kommt man nicht hinaus. Wenn man allerdings mal hergeht und die Taktrate, wie bei jeder PC-UART, laut Protokoll einstellbar macht, dann baut jeder Hersteller sofort die 460kbps ein, weil die lumpigen Chips, die man dafür kaufen kann, das allesamt seit 15 Jahren können.

Um Deine Frage von der anderen Seite her zu beantworten: Sowohl KORG als auch YAMAHA haben öfters ein "to host" interface in ihren Geräten. Das ist genau so eine UART und kann mit jedem Microcontroller zu 3,- das Stück angefahren werden. Das Erstaunliche dabei ist, dass die Reaktion auf diese MIDI-Daten linearer und latenzärmer ist, als z.B. die auf ähnliche Verbindungen über USB späterer Geräte.

Für die die sich da nichts bauen möchten, gibt es die USB2UART-Wandler, die MIDI31,5kHz können und softwareseit als USB-Gerät auftauchen. Das ist dann schon mal eine Lösung, wenn auch nicht unbedingt eine Gute.

Das Problem von USB ist eben einfach die Schichtung, die nicht für Echtzeitanwendungen taugt und niemals taugen wird. Von daher sehe ich weiter Bedarf für eine Lösung wie bei meinem MIDI über S/PDIF. Wenn man nur die Übertragung sieht, ist es möglich, dass die Daten vom einem Master-Keyboard bei bestehender Verbindung (und S/PDIF ist diesbezüglich statisch "an") innerhalb von 64 Takten übertragen werden. Das sind jeweils 2 Audiosamples von z.B. 48kHz oder eben auch 192kHz. Den kritischen Akkordanschlag eines Pianisten mit 10 Fingern und aktueller Velocity (ca. 60 MIDI-Worte) bekommt man damit in maximal 100us in die Syntheseengine. Da ist dann auch der Jitter und die Reihenfolge egal.

 

[engineer]

die dann sicherlich auch eine entsprechend belastungsfähige Schnittstelle besitzen. Die ist doch aber heute mit USB 3.1 und auch USB-C bereits gegeben. Oder verstehe ich da was falsch?

Natürlich, USB hat absolut das Potenzial die Daten in ausreichenden Mengen zu übertragen. Wie oben schon erwähnt, reicht dafür USB2.0 bequem aus. Das Problem ist eher das Management und die Infrastruktur:
USB ist auf Bandbreite gebaut und sendet Pakete. D.h. der Datenstrom kommt diskontinuierlich und unterbrochen. Zudem muss ein Aushandeln erfolgen und es gibt eine Master-Slave-Struktur. Typischerweise ist der PC immer der host, was für die Steuerung der Geräte, z.B. DAW und Synthesizer richtig wäre. Der host hat damit den Datenfluss aktiv in der Hand.

Es wird aber schon interessant, wenn das Endgerät die Quelle ist, wie beim Recording, die Verwendung von USB-Mikrofonen oder MIDI-Controllern. Diese produzieren irgendwann Daten, sind also Erzeuger, werden aber von USB als Clients / Verbraucher gefahren. Der host muss also schauen, dass er die zeitnah abtastet und alles einsammelt, was kommt. Bei den wenigen Daten eines USB-Controllers ist das weniger ein Problem, weil der kaum Daten erzeugt. Trotzdem reicht schon dort die Infrastruktur nicht mehr aus, um es in Echtzeit, also ohne nennenswerte Verzögerung zu tun. Da spielt einfach die USB-Hardware eine Rolle und dies vor allem dann, wenn mehrere Teilnehmer an einem Host-Controller hängen. Beim Recording löst man das so, dass man die Echtzeit ignoriert und die USB-Pakete optimal volllädt und überträgt, um möglichst viele Kanäle störungsfrei zu schaffen. Das bedeutet natürlich, dass man einen USB-Recorder, nicht mehr einfach in die Studiolandschaft einbauen kann und den Signalweg über ein analoges Mischpult, den Wandler und dann wieder in ein weiteres Gerät führt. Da entstehen unkalkuierbare Latenzen, die mit Buffern aufgefangen werden. Das Resoultat sind die bekannten Echos, wenn man aufgenommenes über zwei Pfade monitored.

Wie das mit MIDI 2.0 werden kann, wird dahingehend spannend, wenn versucht wird, Daten in großem Maßstab zu generieren und aufzuzeichnen, wenn also z.B. ein Synthie von mehreren Controllern gesteuert wird und nicht nur dessen Audio, sondern auch die Controller-Bewegungen mitgenommen werden sollen, um es zu automatisieren und zu reproduzieren. Da bei MIDI 2.0 mehr Daten anfallen können und werden, wird das Latenzproblem eher steigen.

Eine gewisse Entlastung ist denkbar, wenn man unterstellt, dass PCs künftig noch mehr parallele UBS host Controller haben werden, um Geräte unabhängig von einander fahren zu können. Nach meinem Empfinden sollten auch USB-Master-Keyboards als host agieren können, wenn man sie mit einem Klangerzeuger verbinden will. Die derzeitige Praxis, sie über den PC zu routen, ist eine ziemliche Gurke.

Nach meiner Vorstellung muss man da mit Audio und MIDI sauber über einen Kanal raus und über andere Kanäle wieder rein.

Meine Zielhardware sieht z.B. so aus, dass ich über S/PDIF aus dem PC gehe, dort die MIDI-Daten reinpacke und sie dem Synthi schicke. Die Daten kommen dann über S/PDIF oder HDMI zurück. Die HDMI-Lösung läuft schon, allerdings habe ich noch keine Verarbeitungsmöglichkeit im PC. Es müsste ja in die DAWs rein. Der S/PDIF out ist in Arbeit: Die DAWs kriegen einen VST-plugin, der wie ein Synthie arbeitet, also MIDI empfängt und Audio generiert, allerdings nichts anderes tut, als die MIDI-Daten ins Audio zu stopfen und auszuleiten.

 

[synthpark]

Natürlich, USB hat absolut das Potenzial die Daten in ausreichenden Mengen zu übertragen. Wie oben schon erwähnt, reicht dafür USB2.0 bequem aus. Das Problem ist eher das Management und die Infrastruktur:
USB ist auf Bandbreite gebaut und sendet Pakete. D.h. der Datenstrom kommt diskontinuierlich und unterbrochen.

kann ich mir schwerlichst vorstellen. USB kennt verschiedene Geräteklassen. Ich müßte jetzt intensiv nachlesen, um die Einzelheiten in Erinnerung zu rufen, die Dokumente sind paar Hundert Seiten dick. Schließlich wartet USB nicht darauf, daß man per Tastatur genug Daten für das Drücken einer einzigen Taste zusammenbekommt.

Edit: mal kurz geschaut:

https://www.beyondlogic.org/usbnutshell/usb4.shtml

The packet length of control transfers in low speed devices must be 8 bytes, high speed devices allow a packet size of 8, 16, 32 or 64 bytes and full speed devices must have a packet size of 64 bytes.

Aber ich sehe, du bist ja auch VHDL-mäßig unterwegs. Ich entwickele seit längerem einen VHDL Synth.

USB ist aber ohnehin komplett ungeeignet als Midi-Synth Schnittstelle. Die galvanische Trennung fehlt. Einer bei Gearslutz meinte, Ethernet wäre eigentlich die richtige Schnittstelle. Kann ich nachvollziehen. Hohe Reichweite, verdrillte Leitungen, galvanische Trennung.

 

[synthpark]

Übrigens noch ein Auszug von USB:
Wer bitte zwingt denn den Soundkartentreiber, die Midi Daten zusammen mit Audio isochron zu übertragen, das ist ja schon etwas bedeppert. Wenn Midi wie eine Maus oder eine Tastatur behandelt werden würde, hätte man die Vorteile kurzer Reaktionszeit etc.

Wenn die Übertragungszeit der Audiopakete sehr kurz ist, kann man mit wenig Jitter Midimessages als eigenständige Pakete dazwischen senden.

Isochronous Transfers

Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream. If there were a delay or retry of data in an audio stream, then you would expect some erratic audio containing glitches. The beat may no longer be in sync. However if a packet or frame was dropped every now and again, it is less likely to be noticed by the listener.

• 
  Isochronous Transfers provide
  • Guaranteed access to USB bandwidth.
  • Bounded latency.
  • Stream Pipe - Unidirectional
  • Error detection via CRC, but no retry or guarantee of delivery.
  • Full & high speed modes only.
  • No data toggling.

 

[Carcinome]

Hier mal Neuigkeiten (?) hierzu:
https://www.amazona.de/alle-informationen-zum-midi-2-0-standard/