L
Lärmbelästigung
Registrierter Benutzer
- Zuletzt hier
- 03.04.21
- Mitglied seit
- 26.12.20
- Beiträge
- 178
- Kekse
- 1.177
Pult-Hersteller bauen selber genug von dem Zeugs ein.
Man muß schon genau hinsehen, wo sie das einbauen. Bisher überwiegend in den teuren Modellen und im FX-Rack. Laut einer Aussage im A&H-Forum ist das z.B. bei den SQ-Pulten kein DEEP-Plugin, weil man damit die Phasenkohärenz brechen würde, auf die man bei dem Pultdesign besonders stolz ist (und die zusammen mit der niedrigen Latenz auch der Grund ist warum ihnen die 96 kHz da so wichtig sind). Kann sein daß das stimmt, kann auch sein daß denen nur das Know-How fehlt - weiß ich nicht. Bei der dLive scheints aufgrund anderer Architektur und anderer Ziele wieder kein Problem zu sein.
In jedem Fall ist allerdings davon auszugehen , daß die in den Pulten verfügbare Rechenleistung ansteigt. Das macht es möglich, mehr und aufwendigere Plugins in die Kanal-Inserts zu packen - sofern dabei nicht prinzipbedingt Latenzen entstehen, die man an der Stelle vielleicht nicht haben will.
Ich glaube, dass das Fehlen der Funktionen letztendlich den Erfolg garantieren wird. Siehe MIDI. Was nützen die Funktionen, wenn kein Hersteller sie vollständig implementiert und man dann am Ende doch wieder nicht einstöpseln und loslegen kann… eben genau das, was ja hier im Fred schon an Dante kritisiert wurde.
Das kommt immer drauf an, wie kompliziert die Implementierung ist.
Bei MIDI ist das Problem, daß die Hersteller Anfangs alles und heute immer noch recht viel in Hardware oder eigener Software machen müssen.
Wenn Du aber mal Internet-Protokolle oder USB ansiehst, läuft sowas ganz anders: da implementiert niemand, der bei Trost ist, das Protokoll selbst. Man benutzt wo immer möglich frei verfügbare Referenz-Implementierungen, die es als Bibliotheken fertig unter LGPL, BSD- oder Apache-Lizenzierung gibt.
Das hat den Vorteil, daß sich der Hersteller genau um diese Funktionen größtenteils gar nicht mehr oder nur noch rudimentär kümmern muß. Die Pulthersteller leiden da noch unter dem NIH-Syndrom oder scheuen sich, sowas in offene Subsysteme auszulagern. Aber das kommt irgendwann - A&H merkt ja mit dem SQ-Drive-Disaster schon daß man mit selbst machen bei sowas nicht weiterkommt.
Kein Pulthersteller wird es sich irgendwann noch leisten können, ein proprietäres Stagebox- oder Bühnennetz-Protokoll am Leben zu erhalten, wenn die anderen einfach nur noch ein zugekauftes I/O-Modul integrieren und an ihren Core anbinden müssen oder wenn die FPGA-Cores so weit standardisiert sind, daß das nur noch ein Softwaremodul und die Anschlußhardware ist.
Sowas passiert grad übrigens im Automobilbau, da hat erst der halbproprietäre (aber schon etwas offenere) CAN-Bus den Markt aufgerollt. Jetzut rücken schon die ersten E-Auto-Hersteller den verbliebenen proprietären Resten zu Leibe. Und wie an so vielen Fronten sind deren Hersteller bereits dabei, das Rückzugsgefecht um die Verteidigung ihrer Märkte zu organisieren, während die Freien ein neues Feature nach dem anderen nachlegen. Es ist strategisch bereits völlig absehbar, wie das irgendwann endet. Selbst wenn man einen freien "Angreifer" abgewürgt kriegt, steht ein paar Monate später der nächste auf.
. Derzeit haben alle entsprechenden Geräte Ethernet für sternförmige Verkabelung, aber wir hatten ja auch schon Zeiten, in denen Ethernet per BNC-Kabel nicht sternförmig war – und daher auch dauernd ausfiel.
Das lag aber nicht an der Topologie, sondern an der Technologie darunter mit Abschlußwiderständen, Koaxialkabeln und fehlender Redundanz. ISDN hat übrigens schon weit besser funktioniert und ist auch ein Bus. ATM ebenfalls.
Übrigens ist das Internet keineswegs ein Stern, sondern in den Backbones ein redundantes Gitter und in den Zweigen ein Baum (strukturierte Verkabelung). Und Ethernet ist zwar physikalisch ein Stern, logisch aber ein Bus bzw. wenn Switche ins Spiel kommen ein Bus-Gitter. Ein Ethernet-Hub ist nichts anderes als ein kollabierter Bus.
Optische Systeme sind als physikalischer Bus nicht möglich, die gehen nur Punkt-zu-Punkt. Das wird also ohnehin nur mit Routing gehen - und wenn man eh routet, bringt ein physikalischer Stern ausfalltechnisch nichts (weshalb man das im Internet mit den Backbones auch nicht macht). Der Unterschied zwischen Audio- und Datennetzen ist allerdings, daß bei Datennetzen Durchsatz das Hauptproblem ist, beim Audionetz Latenz.
Natürlich muß ein Bus- oder Maschensystem wenn das auf der Bühne funktionieren soll komplett selbstorganisierend und redundant sein. Da darf niemand mit IDs, Adressen, Portnummern oder dergleichen in Berührung kommen, das läuft alles automatisch im Hintergrund.