Thema UTP-Kabel
Kein Schirm da, kein Auflegen notwendig. Ganz einfach. Potentialfreiheit bzw. kein verschlepptes Potential inkl. - mit dem Preis der nicht ganz so störfesten Übertragung. Bei kurzen Längen aber unkritisch.
Ja, für Netzwerk-Anwendungen. Aber nicht für AES50, da ist es außerhalb der Spezifikation und kann Probleme verursachen.
Es ging um die Aussage dass einseitiges Schirmauflegen ein definiertes Konzept sei...
Ich habe nicht definiert geschrieben. Es ist ein Konzept, um Brummschleifen zu verhindern. Kennen wir doch auch bei Analog-Audio, Ground Lift. Ich denke nicht, daß wir darauf rumhacken müssen. Es gibt dieses Konzept (im Sinne von: Menschen wenden diese Technik in nennenswertem Umfang an), es ist kein Standard, der Nutzen ist fragwürdig, aber ich denke, wir müssen das auf dem Schirm haben. Wer Wortwitz findet, darf ihn behalten.
Nö, seit es parametrische zu kaufen gibt sind die so sinnvoll wie eine Pferdekutsche im Vergleich zum LKW.
Halte ich in jeder Darbietungsform für komplett überflüssig.
Darauf wollte ich in meinem Beitrag ja auch hinaus, ich habe es nur freundlich formuliert.
Nein. Das ist kein Konzept - das ist Murks. Wie niggles schon beschrieben hat gehören bei strukturierter Netzwerkverkabelung beide Enden schirmmäßig aufgelegt. An Patchfeldern auf PE.
Wie passt dann ein UTP-Kabel in diese Aussage? Diese Kabel existieren ja. Ich rede ausdrücklich nicht von Hausverkabelung, sondern von Patchkabeln.
Und nochmal, ich weiß nicht, ob es bereits geschrieben wurde 
Bei AES50 handelt es sich nicht um ein Netzwerk.
Ein weiterer Gedanke, könnte diese Art strukturierter Netzwerkverkabelung eins der Probleme für AES50 sein? Schließlich haben die Endgeräte nicht zwingend das gleiche Potential.
Das ist jetzt interessant... Wer hat denn das als Konzept definiert?
In der IT gibt es kein "Floating Ground". Da wird alles was abgeschirmtes Kupfer von Patchpanel zu Patchpanel ist an beiden Enden hart mit dem PA des Gebäudes bzw. "Medienerde" verbunden, schon allein deswegen um Potentialverschleppung in die Endgeräte (deren Anschlussdosen idR keine eigene Verbindung zum PA haben) möglichst zu vermeiden. Verbindungen zwischen Switches die hier zu Problemen neigen (alles was "vertikal" ist, horizontale Querverbindungen zwischen Gebäudeteilen mit deutlich unterschiedlicher Baugeschichte) werden da schon lange nur noch in Glas ausgeführt.
Da war ich ungenau. Ich meinte nicht die Hausverkabelung. Es gibt verschiedene Ideen, Patchkabel auszuführen. Bei UTP ist es klar, sobald ein Shield im Kabel ist, scheiden sich die Geister. Und ein Konzept ist, nur eine Seite des Shields aufzulegen, die andere Seite floaten zu lassen. Ob das bessere oder schlechtere Ergebnisse erzielt, hängt von der konkreten Situation ab.
Mit Deiner Erwähnung von Glas-Verbindungen bringst Du ein Thema auf, was nach meiner Erfahrung bei AES50 auch ein Rolle spielt. Die stabilsten AES50-Verbindungen habe ich mit folgendem Konzept erzielt: Netzwerkkabel nach Spezifikation, Erde durchverbunden und auf die EtherCon-Shells aufgelegt, Stromkabel in gleicher Länge parallel dazu.
du hast ja Recht, nimm die richtigen Kabel und alles ist OK, aber wie hier doch vermehrt geschrieben wird, findet vermehrt die Verlegung von Cat7 statt. Also war jetzt meine Überlegung, die wirkliche Ursache zu finden und eine Anpassung zu schaffen. Wenn ich auf eine Baustelle komme und es liegt schon Kabel was ich nutzen kann, warum soll ich erst welches legen wenn ein Adapter das Problem löst. Es gibt doch die verschiedensten Anwendungen wo durch entsprechende Anpassung Kabel zweckentfremdet werden. Daher die Sache mit der Messung.
Die Denkweise kann ich verstehen. Sie entspringt aber dem Gedanken, daß da ein nutzbares Kabel liegt. Das stimmt halt einfach nicht. Richtig ist: Da liegt ein Netzwerkkabel. Kein AES50-Kabel. Ich komme ja auch nicht auf die Idee, ein vorhandenes Cat7-Kabel irgendwie auf Coax zu adaptieren, wenn ich MADI benutze.
Empfohlen ist ja ein auf Ethercon terminiertes durchgehendes Kabel in der Spezifikation Cat5e. Ethercon mit durchgehender Masseverbindung wäre noch wichtig, zu erwähnen. Das steht diametral zum floating ground-Konzept bei Netzwerk-Verkabelung. Daraufhin wird auch die Stromversorgung des FOH relevant.
Hoffentlich nicht.
Ich inserte sehr selten GEQs, und wenn ich die alle händisch entfernen müßte wäre das ein klarer Minuspunkt. Mixbusse kann man für alles mögliche verwenden, nicht nur als Ausspielwege, und selbst für Ausspielwege benutzen viele Tonler*innen keine „31 Bänder“
31-Bänder sind sinnvoll. Als Hardware im Rack. Dann kann man mit einem Finger wenn nötig auf allen Monitorwegen eine Frequenz ziehen. Und dann Weg für Weg abklopfen, wo das Problem genau lag. Vorteile sind also Schnelligkeit und Übersicht. GEQs in Digitalpulten können das nicht, sind daher ihrer Vorteile beraubt und inhärent den PEQs unterlegen.
Bin also völlig bei Dir, das ist allenfalls ein Legacy-Tool, nichts, was benötigt wird.
Aber was nützt dir dabei die praktische Erfahrung wenn die Theorie sagt, das andere Kabel auch funktionieren müssten?
Ich habe langsam die ganzen Theoretiker in meinem Umfeld satt, die mir immer wieder versichern, das etwas gehen müsste aber in der Praxis kläglich versagen.
Mir reicht die Praxis, ehrlich gesagt. Sicherlich könnte man das ganz genau herausfinden, warum genau Cat7 Probleme macht. Das wäre doch mal eine Aufgabe für die besagten Theoretiker in Deinem Umfeld. Fordere sie doch heraus. Und poste dann, was sie herausgefunden haben. Eine bestimmte Eigenschaft von Cat7 wird es sein.
Das wäre mal eine interessante Messung wert wie groß die Unterschiede in der Laufzeit bei Cat7 sind. Schade, aber dafür habe ich leider keine geeignete Messtechnik.
Ich weiß nicht, ob das den Aufwand wert ist. AES50 kommt Ja erwiesenermaßen oft mit Cat7-Verkabelungen nicht klar. Wozu dann noch messen?
Bin da Pragmatiker. Einfach Kabel benutzen, die den Spezifikationen entsprechen und keinen Streß haben. Ist ja nicht sonderlich schwer.
Wobei ich als Nachrichtentechniker immer noch auf der Suche nach der physikalischen Erklärung bin. Denn wenn die Impedanz stimmt und die Dämpfung bei den benötigten Frequenzen gering genug ist, dann gibt es eigentlich keinen Grund, warum ein CAT.7 Kabel hier versagen sollte.
Probleme, die mir bei Cat7 spontan einfallen:
Stärkere Verdrillung, dadurch mehr Länge pro Meter.
Verschiedene Längen der Aderpaare.
AES50 nutzt ja die 4 Paare folgendermaßen: Audio hin, Audio rück, Sync hin, Sync rück. Abweichungen in der Länge sind da massiv störend. Und die Verdrillung und Verseilung bei Cat7 scheint auch nicht optimal für diese Nutzung zu sein.
Nächster Punkt: RJ45 ist als Steckverbindung für Cat7 nicht geeignet. So terminiert bekommt Cat7 sie PS nicht auf die Straße. (platt gesagt)
Dazu kommt, daß AES50 SEHR wählerisch ist, was Abschirmung und Erdung betrifft. Gängig sind geschirmte Aderpaare und eine durchgehende Erdung zwischen den beiden Geräten.
Unter dem Strich heißt das, daß Cat7 zwar besser als und kompatibel zu Cat6 und Cat5 ist, wenn es im Ethernet benutzt wird, aber bei AES50 sieht es anders aus.
Da ja der Ursprung dieser Diskussion Probleme von Audionetzwerken war, würde mich an dieser Stelle interessieren, was sind die Gründe warum denn nun AES50 mit Cat7 Zicken macht? Ich vermute mal, bei der Anpassung der Schnittstelle hat man sich nicht unbedingt viel Mühe gegeben. Für mein Verständnis sollte ein Cat7 Kabel qualitativ besser sein als Cat5.
Einfach gesagt ist es die Tatsache, daß AES50 kein Audionetzwerk ist. Es wird lediglich der Hardware-Layer genutzt und das in einer sehr anderen Art als Ethernet das tut. Deshalb gilt für dieses Protokoll eben nicht, daß Cat7 qualitativ besser ist als Cat5.
Es ist wichtig, diesen Unterschied zu kennen und sich einfach an die Kabelspezifikationen zu halten.
Wie setzt du das denn in der Praxis dann um? Legst du alle Kanäle * Monitorwege auf? Gar keine Kompression auf Gesängen? Irgendwie muss das ja auch noch händelbar sein
Wie geschrieben, mit Nodal Processing kein Problem.
Ohne sieht es so aus:
Die wichtigen "me"-Kanäle doppelt aufgelegt, ein Mal für "me", ein Mal für die Anderen. Das ist ggf. ein bißchen Aufwand, der sich aber lohnt. Es muß auch nicht immer bei allen Kanälen sein. Es gibt auch Pulte, bei denen man den Aux-Abgriff pro Kanal und Aux pre/post dynamics schalten kann.
Was verstehst Du unter Nodal Processing?
Ein Begriff von DiGiCo. Man kann bei den Quantum-Konsolen Processing pro Abgriff machen, also je nach Ziel-Aux unterschiedlichen EQ und Dynamics anwenden. Nicht direkt unbegrenzt, das würde dann doch den Rahmen sprengen, aber es ist trotzdem ein mächtiges Tool am Monitorplatz.
IWMO:
Musik mischen. In dem Fall Open Air Band + Orchester + Chor + Solisten. Pult voll, Herz auch.
Gutes Thema, weil es inzwischen durchaus zum Problem wird.
Erste Regel für mich: das eigene Signal wird nicht komprimiert. Was schwieriger ist, als gedacht. Denn Summenkompression wirkt ja auch auf das "me"-Signal. Und wenn man IEM-Sendestrecken "heiß" fährt, muß man das fast zwangsläufig tun.
Zweite Regel: andere Signale sehr gerne komprimieren. Was nach Nodal Processing schreit.
Ich habe noch nie dem Wunsch verspürt, für mehr als 4/4 Kanäle einen Lake-Prozessor zu nutzen.
In System-Amps cool, zur Signalverteilung sehr umständlich. Was auch Sinn ergibt, wenn man sich die Historie von Lake anschaut.
Als Matrix würde ich einen Newton o.Ä. nutzen. Da kommen dann auch erstmal keine Wünsche nach mehr Ein- oder Ausgängen auf.
Mir wäre jetzt kein einziger Synthesizer bekannt welcher Dante schickt 🤔
Jeder Software-Synthesizer, basically.
Alles anzeigenAber ist nicht oft der technische „Rider“ Teil des Vertrages?
Wir hatten mal eine Band die korrekt feststellte, dass die Bühnengröße nicht gemäß Rider war und sie erfolgreich eine größere Bühne forderten.
Es ist schon wichtig zu wissen welche Rider man zu welchem Grad ignorieren kann und welche nicht.
Ich finde es auch wichtig bei totalem „Mismatch“ seinen Kunden zu bitten das zu klären, zB. „ist der Band bewußt, dass dieses Venue sehr weit weg von den Anforderungen im Rider ist?“ - auch bei Bands wo es nicht strikt Vertragsbestandteil ist.
Erwartungsmanagement (managing expectations) ist IMHO eine Schlüsselkompetenz unserer Branche.
"Rider" heißt streng genommen genau das. Eine Zusatzvereinbarung, die Teil des Hauptvertrages wird. Er reitet sozusagen auf dem Hauptvertrag. Zuerst bekannt geworden in der Versicherungswirtschaft, später von Bands und Bandmanagements übernommen.
Jetzt ist es in der Branche so, daß viele Bands das Ding zwar Rider nennen, es aber kein Rider ist, weil die vertragsrechtliche Komponente nicht erfolgreich vereinbart wurde. Da wird es dann schwierig.
Ich fände es toll, wenn wir auf der Ebene eine andere Begrifflichkeit wählen könnten. Warum etwas "Rider" nennen, wenn es kein Rider ist?
Eine Cover-Band mit der ich an und zu unterwegs war, nannte das Dokument "technische Information" und es gab einen Stageplot, eine Inputlist, pro Musiker und für die FOH-Position eine Auflistung von Equipment, welches mitgebracht wird, was gebraucht wird und was "nice to have" ist. Das Advancing auf Basis dieses Dokuments empfand ich immer als sehr angenehm.
Ich habe es ein Mal erlebt, daß bei einem recht hochstehenden Gig eine Band beinahe nicht auf die Bühne gegangen wäre, weil der Rider nicht erfüllt wurde.
Bei voller Gagenzahlung und mit aufgetanktem Privatjet am nahe gelegenen Flughafen. Am Ende wurde ein Kompromiss gefunden, aber die Band wäre im Recht gewesen, weil der Rider Vertragsbestandteil war und die Nichterfüllung ein Vertragsbruch seitens des Veranstalters.
Für mich war das besonders aufregend, weil ich der von der deutschen Agentur bestellte technische Koordinator war, das also dem Produktionsleiter beibringen musste, der wiederum mit den Vorständen eines der größten 10 Unternehmen Deutschlands reden musste, damit das am Ende doch noch klappt mit dem Auftritt.
Es ging dabei nicht mal um technische Dinge, da konnten wir schon vorher Einiges ändern, die Anforderungen wären in der Location nicht erfüllbar gewesen.
Was will ich mit dem Beispiel sagen? Es handelt sich zunächst mal um einen Vertrag zwischen Band und Veranstalter. Den Dienstleister betrifft der Rider zunächst nicht. Außer, es gibt einen Vertrag zwischen Veranstalter und Dienstleister, in dem steht, daß der Rider erfüllt wird (die Teile, die zutreffend sind). Wenn man das als Dienstleister macht, sollte man sich sehr sicher sein, daß man dazu in der Lage ist, dazu gehört natürlich, daß man den Rider vorher gelesen hat. Und daß nicht danach ein "Update" des Riders eintrudelt. Also sehr spezifisch im Vertrag festhalten "den technischen Teil des Riders der Band XY in der Version Z vom -Datum- erfüllen wir mit unserem Angebot. Andernfalls entstehen heftige Haftungsrisiken. In dem von mir genannten Fall ging es um grob eine viertel Million Euro.
Ich empfehle, sehr deutlich zu machen, daß technische Anforderungen aus einem Rider (oder mehreren) selbstverständlich zusätzlich berechnet werden.
Dann gibt es noch das Dokument, was wir gerne "Rider" nennen, was aber keiner ist, weil er nicht Vertragsbestandteil ist. Der Begriff "Rider" ist dann irreführend, weil er im Kern genau das bezeichnet, eine Zusatzvereinbarung, die Teil des Vertrages ist. Anyway, also diese sogenannten "Rider" sind technische Informationen, die die Arbeit erleichtern, aber rechtlich keinen Anspruch auf eine bestimmte technische Ausstattung ergeben.
Festival-Bandtechniker, FOH:
Für den Job brauche ich inzwischen extrem wenig. Gute Local Crew vorausgesetzt. Der Job ist ja mischen. Den Rest setze ich voraus.
Kopfhörer
Je nach Pult ggf. Beschriftungsband und Sharpie
USB-Stick
Talkbackmikro (seit meiner Zweitausbildung als Rettungssanitäter bin ich da irgendwie picky geworden)
Schülke-Desi (gleicher Hintergrund)
Sonnencreme
Wasserflasche und Thermosbecher für Kaffee bzw. Tee (ich hasse inzwischen offene Getränke am Pult, das lenkt mich mega ab)
Monitor:
zusätzlich InEars, wenn ich auf InEars mische
iPad + Nanostation
zusätzlich je nach Situation mehr Material, gute Mikros, gute HF-Kabel z.B. Kommt sehr auf die Band und auf die Situation an.
