was wĂ€re der groĂe Vorteil?
dafĂŒr mĂŒsste man so viele RĂ€der neu erfinden, es gibt doch fĂŒr alles schon etablierte Protokolle...
Adressierung & Routing -> IP
Fehlererkennung & Ports -> TCP
wieso nicht einfach ein MIDI-Paket in ein TCP-Paket stecken und ab die Post?
Weil man dann die Garantie verliert, dass Pakete so schnell wie möglich und mit wenig Jitter ankommen. MIDIoTCP mĂŒsste man z.B. mit Zeitstempeln versehen, auf die sich alle Kommunikanten erstmal einigen mĂŒssten. Bei MIDIoUDP weisst Du wiederum nicht, ob Du alles bekommen hast was jemand geschickt hat. Deshalb unterstĂŒtzt der RFC fĂŒr RTP MIDI auch sowohl UDP als auch TCP und kĂŒmmert sich exakt genau da drum.
[Irgendwas mit] Ethernet ist schon sehr attraktiv. Super verfĂŒgbar und gĂŒnstig, gut geeignet fĂŒr Echtzeit und geringe Latenzen (ganz grob IP-LAN < 1 ms, IP-WLAN 10 ms, MIDI 5 ms, USB2 in HW ~1 ms, USB2-im-OS-Treiber grob 10 ms) und Bandbreiten die im Vergleich zu MIDI vernachlĂ€ssigter sind - wir reden von vielen Mbps Ethernet vs. 31 kbps MIDI.
FĂŒr die Nerds ein paar Gedanken:
Der RFC fĂŒr RTP MIDI ist schon wirklich gut durchdacht. WorĂŒber wir hier im Thread reden - potentiell riesige Synthesizermuseeen mit MIDI-Setups, die sich leicht umkonfigurierten lassen, tight und billig sind, sind ein Nischenthema. Das hat denke ich einfach zu wenig Marktwumms, als dass die Sachen von einem Konsortium weggefrĂŒhstĂŒckt wĂŒrden. "Die Industrie" ist eh schon eher klein und hat (noch?) nicht wirklich einen Vorteil davon, das mal sauber zu implentieren. MIDI-DIN reicht doch, ist billig und hat 1a Support. Roland und Sequential mussten damals in den 80ern wirklich ein Problem lösen - die Studios konnten es sich schlicht nicht leisten, fĂŒr jede einzelne digitale Kiste eine eigene BespaĂungsinfrastruktur mitzuschleppen - sei's Keyboard, Sequenzer, Patch-Management, Synchronisation oder was auch immer. Kostet alles Platz, Geld, Wissen und damit Verkaufszahlen. Heute sind diese Probleme aus Sicht der Hersteller hinreichend gut gelöst.
MIDI hat zwei gegenlĂ€ufige Anforderungen: Echtzeit (= geringe, konstante Latenz) und IntegritĂ€t (= Transportgarantie+Fehlererfreiheit). Andere Faktoren sind hier nicht so wichtig z.B. garantierte Bandbreite (drĂŒcken ja nicht immer 10 Finger gleichzeitig auf fĂŒr Tasten) oder SynchronitĂ€t (normaleweise sendet genau eine Stelle an genau ein Ziel, das dabei nur zuhört und nicht selbst noch sendet).
Bei den Basics fĂŒr ein Protokoll ĂŒber Ethernet schaut's wie folgt aus:
Auf Layer 2 (Ethernet mit MAC-Adresse ohne IP) haste den Vorteil,
- bei vernachlĂ€ssigteren Latenzen (<< 1ms) gĂŒnstig Hardware nutzen zu können (Kabel, Hubs & Switches).
- Man könnte alles, was Ethernet kann, nutzen (z.B. WLAN, LAN auf Kupferbasis, Glasfaser).
Nachteil:
- kein Routing möglich (die Kommunikationsendpunkte wie Synth und Seq mĂŒssen sich "sehen", kannst also nicht aus einer Kabelwelt mit mehreren Hubs, Switches und ggfs. Medienkonvertern raus).
- Man muss Punkt-zu-Multipunkt (z.B. Timecode-Frames) selber basteln
- man sollte eigene Kabel fĂŒr MIDI-over-Ethernet und andere -over-Ethernet (DANTE, AVB, Internet usw.) nehmen, obwohl genug Bandbreite da wĂ€re
Layer 3 (IP) hĂ€tte mMn alle möglichen Nachteile, weil man alles Mögliche (s.o. Echtzeit und IntegritĂ€t) selbst basteln mĂŒsste und brĂ€chte kaum was ggĂŒ. Layer 2 oder Layer 4.
Nimmt man UDP/IP oder TCP/IP (Layer 4), kann man auf jeden Fall "Echtzeit" und "IntegritÀt" machen, muss aber jew. eine Seite davon selber basteln.
RTP MIDI geht aber noch weit darĂŒber hinaus. Da kannste z.B. MIDI-Messages auf Deine 192 kHz Audio-Clock synchronisieren und solche SpĂ€Ăe. Ich fand's jedenfalls cool, wenn das im Lauf der Zeit mehr Momentum entwickeln wĂŒrde. Ein Ethernet-Interface in MusikgerĂ€te und DAWs einzubauen ist jetzt nicht so die HĂŒrde...
Bin da ganz bei microbug - mehr RTP und gut is
Ein paar Quellen:
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network...
tools.ietf.org
This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different...
tools.ietf.org
Das OSI-7-Schichtenmodell ist ein Referenzmodell fĂŒr herstellerunabhĂ€ngige Kommunikationssysteme. OSI bedeutet Open System Interconnection (Offenes System fĂŒr Kommunikationsverbindungen).
www.elektronik-kompendium.de
de.wikipedia.org
und die Seite ist down Copperlan.org und macht einen auf Mode
ob's das braucht - keine Ahnung... es funktioniert auf jeden Fall sehr stabil und schnell
wollte mal RTP in einer eigenen Anwendung anbinden, aber mir war es dann einfach zu umstĂ€ndlich. So richtig leichtgewichtig ist das nicht und bei vielen Dingen hab ich mich gefragt ob es das jetzt wirklich braucht bzw. hatte das GefĂŒhl, die bauen da irgendwie ihr eigenes TCP basierend auf UDP mit manueller Fehlerkorrektur, Verbindungsaufbau und Sessions.
