Copperlan R.I.P?

HomerSX
HomerSX
...
Anscheinend ist es jetzt endgültig um Copperlan geschehen 🤯 und die Seite ist down Copperlan.org und macht einen auf Mode😱
Google.
Wenn man viel Hardware im Einsatz hat war es die einzige vernüftige Möglichkeit MIDI zu verteilen ohne lange In/Thru/Out Ketten insbesondere zusammen mit den Alyseum AL-88c....
Sehr Schade, drück die Daumen das die Community es wieder zum Leben erwecken kann.
 
Mesmerised
Mesmerised
General Gear
Tja... Ich hatte es auch schon befürchtet! Ich hatte vor 5 Jahren in 4 AL-88c investiert und finde das System echt klasse - abgesehen von ein paar Bugs, die man noch fixen müsste. Das wird jetzt wohl nicht mehr passieren. :heul:
 
verstaerker
verstaerker
*****
ich hab hier derzeit 5 AL-88C in Betrieb (der 5. kam diese Woche hinzu) und bin sehr zufrieden.

Den Manager gits noch zum Download

Sehr schade das das Projekt den Bach runterging. Die hatten schon eine 2.0 Version in der Mache die fast im Beta-Stadium war. Ich würde da investieren wenn sich irgendjemand des Projekts annehmen würde.
 
Max
Max
|||||
RIP... wir brauchen dringend eine moderne Alternative!

Ich finde sowohl Copperlan als auch RTP-MIDI etwas zu schwergewichtig - mir schwebt da ein ganz simples "MIDI over TCP"-Protokoll vor... (gibt auch schon ein paar Projekte in die Richtung)

Herausforderungen:
  • Breakout-Box
  • Konfigurations-Software
  • Virtuelle Treiber

Hier im Forum ist doch die geballte Kompetenz versammelt um einen würdigen Nachfolger als Open-Source-Projekt auf die Beine zu stellen 🙌✊💪
 
verstaerker
verstaerker
*****
RIP... wir brauchen dringend eine moderne Alternative!

Ich finde sowohl Copperlan als auch RTP-MIDI etwas zu schwergewichtig - mir schwebt da ein ganz simples "MIDI over TCP"-Protokoll vor... (gibt auch schon ein paar Projekte in die Richtung)

Herausforderungen:
  • Breakout-Box
  • Konfigurations-Software
  • Virtuelle Treiber

Hier im Forum ist doch die geballte Kompetenz versammelt um einen würdigen Nachfolger als Open-Source-Projekt auf die Beine zu stellen 🙌✊💪
das klingt cool und ich würde so ein Projekt unterstützen, aber Programmieren kann ich nicht so gut. Aber bei der Finanzierung und Konzeption kann ich helfen.

Als Ideenbasis schwebt mir die Copperlan-Software vor. Die müsste man modernisieren.

Ein neues Protokoll erfinden erscheint mir etwas drüber. Mir ist aber auch nicht bewusst was an RTP-Midi zu schwergewichtig ist. Ich würde meinen es ist ne gute Basis und spart jede Menge Entwicklungsaufwand.

Was die Hardware angeht könnte man dann vermutlich auch auf existierende Lösungen setzen die schon RTP können. Also alte Alyseum AL-88s, iConnectivity Mios (ich find die mitgelieferte Software ein absolute Zumutung)
 
Max
Max
|||||
Ich find den ganzen Verbindungsaufbau bei RTP etwas zu kompliziert, Invitations, Sessions usw. und auch die Verwendung von UDP mit einer selbstgestrickten Fehlererkennung find ich etwas seltsam. Das macht es dann halt gleich schwer, einen Client dafür zu schreiben, weil man diese Dinge dann alle implementieren muss.

Wieso nicht gleich TCP verwenden und mit festen IP-Adressen und Ports arbeiten?

Copperlan baut auch nicht auf RTP auf, die benutzen meines Wissens nicht einmal TCP oder UDP sondern direkt IP
 
C
coripeter
...
Also auf meinem Win7 Rechner ist der Copperlanmanager an ein Interface ohne IP-protokoll gebunden und es geht auch,
wahrscheinlich wohl nur über die Mac-adresse.
ich habe ein MS-812 und ein AL-22c dran und über den Manager ist noch ein Mac dran, über Gbit geht das ganz gut.
 
C
coripeter
...
Eins von den beiden Gbit ETH Adaptern auf dem Motherboard.
In den Eigenschaften von Lan Adapter 2 :
Copperlan aktiviert und Ip V4 und V6 deaktivert...
Über den Lan Adapter 1 geht das Internet ...
wenn man den rauszieht geht Copperlan immernoch aber ich habe kein Internet oder internes Netzwerk.
 
Max
Max
|||||
jetzt wo du es sagst, erinner ich mich auch wieder - Copperlan benutzt nicht mal IP sondern setzt direkt auf Ethernet auf 😯 ob's das braucht - keine Ahnung... es funktioniert auf jeden Fall sehr stabil und schnell

meiner Meinung nach wäre eine Lösung "MIDI over TCP" völlig ausreichend, man muss ja nicht das Rad neu erfinden
 
lowcust
lowcust
|||||
coripeter hat es schon angesprochen, man könnte alles via mac-address wie an einem Switch lösen man müsste sich nicht ums IP Netz scherren.
 
Max
Max
|||||
coripeter hat es schon angesprochen, man könnte alles via mac-address wie an einem Switch lösen man müsste sich nicht ums IP Netz scherren.

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?
 
C
coripeter
...
Naja routing ist da nicht drin, und bei IP giebt es auch Priorytäten.
Ich fand nur einfach gut das ich alle Midi-Interfaces (an jedem Rechner ein Fireface 400) benutzen konnte.
 
microbug
microbug
MIDI Inquisator
Ich hoffe ja immer noch, daß MOTU mal MIDI in AVB bzw TSN einbaut, das wäre ebenfalls über Ethernet, braucht aber im Gegensatz zu RTP Chips, die das unterstützen.

Ansonsten tut es RTP ganz hervorragend, sollten einfach ein paar mehr Hersteller integrieren. Tut nicht not, das Rad neu zu erfinden.
 
SID6581
SID6581
...
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:
 
Max
Max
|||||
Danke für die ausführlichen Ausführungen!

Ja, UDP ist etwas schneller, aber wenn ich dann selbst nochmal eine Fehlerbehandlung wie bei TCP implementiere, kann ich mir nicht vostellen dass da wesentlich mehr als die ein oder andere Mikrosekunde drin ist (der Grund wieso UDP schneller ist, liegt ja zum Großteil daran, dass eben auf die Fehlerbehandlung verzichtet wird).

Ich gebe zu ich hab die RFC's nicht gelesen 😅 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.

Der nächste Punkt ist ja dann auch noch ob alle diese Faktoren in einem lokalen (!) Netzwerk wirklich so kriegsentscheidend sind, man darf ja nicht vergessen dass es darum geht ein Protokoll aus den 80er Jahren über eine um viele viele Größenordnungen schnellere moderne Infrastruktur zu schicken.

Vielleicht tut sich ja noch was in die Richtung, vom Ansatz sind die MIO Interfaces schon super und stabil & schnell scheint es ja wirklich zu sein - wenn man es dann irgendwann hoffentlich so komfortabel wie Copperlan konfigurieren kann werd ich auch umsteigen.
 
verstaerker
verstaerker
*****
wenn man es dann irgendwann hoffentlich so komfortabel wie Copperlan konfigurieren kann
vielleicht müsste man denen nochmal verdeutlichen wie umständlich ihr Routing-System ist. Aber ob die das für die doch eher überschaubare Zielgruppe anpassen ...
 
microbug
microbug
MIDI Inquisator
Ein Ethernet-Interface in Musikgeräte und DAWs einzubauen ist jetzt nicht so die Hürde...

... zumal DAWs das bereits problemlos können, wenn das drunterliegende OS es beherrscht, was für MacOS mit nativer Unterstützung und Windows mit den Treiber von Tobias Erichsen längst der Fall ist.

Hardwaresynths mit Ethernetschnittstelle gibts auch schon: Moog One, Modal 001,002,008 etc. Wird nur bei denen nicht dafür benutzt. Moog könnte das allerdings einbauen, wäre dann der erste Synth mit nativer RTP MIDI Unterstützung.
 
Max
Max
|||||
Hat eigentlich noch jemand den Installer für den Copperlan Manager irgendwo rumliegen?

Wär cool wenn wir den hier archivieren könnten! (PC + Mac)

Ich hab ihn leider nirgendwo mehr gefunden...
 
Klangzaun
Klangzaun
!!!11!111
Naja, als Alternative zum Copperlan gibt es ja auch noch Interfaces wie das

ESI M8U eX

oder

Miditech Midiface 16x16
 
Max
Max
|||||
@Klangzaun das sind leider keine wirklichen Alternativen, denn Copperlan ist kein reines Interface, sondern ein verteiltes System für große MIDI-Setups - es läuft z.B. auch komplett Standalone ohne Computer oder wahlweise auch mit mehreren Computern gleichzeitig. Über Netzwerk kann man nahezu beliebig viele Breakout-Boxen und Rechner integrieren und MIDI-Daten untereinander routen, verteilen mergen etc. wie man will

Die einzige Alternative momentan sind RTP-MIDI basierte Systeme wie iConnectivity MIDI, es gibt auch ein paar kleinere Projekte in die Richtung wie das oben von @verstaerker verlinkte Cinara - aber so richtig toll funktioniert das wohl noch nicht, die Konfiguration scheint sehr umständlich zu sein. Vermutlich ist das aber die Zukunft...
 
Klangzaun
Klangzaun
!!!11!111
Nunja, ich habe mein Copperlan (welches mit zunehmender Komplexität auch die Konfiguration „vergessen“ hat) ersetzt.
 
Max
Max
|||||
ok, das Problem mit "Konfiguration vergessen" ist bei mir noch kein einziges Mal aufgetreten - ich hab aber auch nur 3 Boxen und 2 Rechner verbunden

ein wichtiger Vorteil für mich ist neben dem Standalone-Betrieb auch die "Dezentralität", mein Studio ist ziemlich im Raum verteilt und durch die Boxen spart man sich die sternförmige Verkabelung mit vielen sehr langen Kabeln
 
verstaerker
verstaerker
*****
vor allem kann ich leicht nachschauen was womit verbunden ist und es mal temporär ändern... mit nem normalen midisetup undenkbar
 
 


News

Oben