Allen & Heath GLD 80 - Erfahrungsberichte

Zitat von "mike j."

Der Anschluss einer Tastatur funktioniert (man kann auch die Ebenen von Linux mit ALT+Fx umschalten) oder Channelstrips benamseln.

Das würde mich interessieren. Welche Tastatur (Modellbezeichnung) hast du da angesteckt? Sowohl eine Cherry und eine Logitech die ich hier hatte haben beide nicht funktioniert. Firmware-Version deiner GLD? Achso: Das was du eine "Ebene" nennst heißt korrekt "virtuelle Konsole", mehr Infos z.B. hier.

Zitat von "mike j."

Das kann aber auch daran liegen, dass sie NTFS formatiert war.

Sehr wahrscheinlich. Der im Kernel integrierte NTFS-Treiber hat nur eingeschränkte Unterstützung für Schreiboperationen. Es gibt zwar einen externen FUSE-Treiber namens NTFS-3G, aber das wird A&H sich sicher nicht ans Bein gebunden haben. Warum auch. Ist schließlich ein Mischpult mit Media-Player-Feature und kein Media-Player mit Mischpult-Feature.

Zitat von "mike j."

dSnake => Dante Karte Primary Slot => vom Secondary übers Core auf die Bühne in die Stagebox - funktioniert überhaupt nicht. Hintergedanke dabei war, Dante und dSnake über ein Kabel zu übertragen. Das geht wohl nur mit Layer 3 Switches.

Da der dSNAKE-Port an der GLD mit an Sicherheit grenzender Wahrscheinlichkeit kein Gigabit spricht, ziehst du dir mit dieser Aktion die Dante-Karte auch auf Fast-Ethernet runter. Da dSNAKE die Verbindung bereits nahezu sättigt, gehen jetzt durch den zusätzlichen Dante-Verkehr massiv Pakete verloren. Folge: Es geht nichts. Getestet habe ich das selbst nicht, aber das ist für mich die logische Erklärung. Mit sog. "Layer 3 Switches" hat das nichts zu tun. Möglich wäre dein Vorhaben mit je einem VLAN-fähigen Switch sowohl am Pult als auch an der AR2412, darauf je einen Port untagged in das GLD-VLAN bzw. das Dante-VLAN, einen dritten tagged für beide VLANs konfigurieren und die beiden Switches über diesen verbinden. Grafik zur verständlichen Erklärung wird nachgeliefert.

Zitat von "mike j."

[Ausfall der Kabelverbindung] Macht es hier Sinn ein 2. Kabel mitzunehmen als Ersatz (kosten ja nicht die Welt)

Wenn die Zeit dafür da ist, du es vorher auf einem anderen Weg verlegt und vorbereitet hast, warum nicht? Umstecken und es geht weiter. Wenn es so wichtig ist, kann man natürlich die Redundanz ohne Umstecken auf Netzwerk-Ebene mit Switches für die GLD einrichten, sowas ist aber jetzt nicht grade Plug&Play und auch kein Feature der ganz billigen Switch-Hardware. Dann doch eher ein anderes System, was die Redundanz bereits drin hat. Geht für iLive z.B. mit ACE oder auch MADI (mit separatem Netzwerk) um mal zwei Beispiele zu nennen.

Grüße
Joern

Hallo,

Zitat

Das würde mich interessieren.

Version = v1.02, Tastatur = Logitech K120 (so ein billiges Ding wo irgendwo einmal dabei war).
=> Video: http://mediaportal.audiowerk.a…rum2/gld_keyboard.avi.flv

Zitat

Mit sog. "Layer 3 Switches" hat das nichts zu tun.

Jetzt wo ichs lese... ich meine VLANs, sprich Ports auf eine Leitung zusammenführen und hinten wieder auseinander. Werd ich wenn ich Zeit habe einmal versuchen, hab hier 2 kleine Switches da, die das können sollten.

Ich denke nicht das VLANs etwas bringen, wenn der Switch nicht auf QoS kann um die VLANS zu priorisieren. Ob die Daten nun sichtbar oder unsichtbar über das gleiche Kabel gehen, macht quais keinen unterschied. In der IT werden VLANs aus Sicherheitsgründen genutzt und zur Priorisierung (VoIP) von Daten.. aber nicht weil es unterschiedliche Bandbreiten an den Endgeräte Ports gibt. Wichtig ist die Strecke zwischen den Switchen.

Doch doch, im Normalfall funktioniert genau sowas mit VLANs. Nur muss die Strecke zwischen den beiden Switches natürlich alle Pakete möglichst in Echtzeit übertragen können, also als Grundvoraussetzung die aufaddierte Bandbreite bereitstellen. Wenn dSnake schon fast 100MBit "frisst", darf die Verbindung mit Dante und dSnake drauf natürlich nicht auch nur 100MBit sein. Jetzt wäre nur noch die Frage, ob dSnake so timingkritisch ist, dass kleine Unstimmigkeiten das Protokoll aus der Bahn werfen. Da warten wir mal den angesagten Test ab.

Verbindungen über normale Switches gehen sicherlich auch, aber man müsste einen finden, der nicht zwischendurch noch selbst irgendwelche Pakete rausschickt (das machen Switches, um z.B. die "Nachbarschaft" zu erkunden und Routen zu finden). Allerdings kann man eh nichts anderes über die selbe Verbindung laufen lassen, wenn man das Ganze nicht als VLAN tagt, somit könnte man so nur die Leitungslänge erhöhen.

So, hier zunächst mal das Bild zur Erklärung, was da jetzt wo wie gesteckt und konfiguriert wird:

Wofür das alles? Wir fassen den Verkehr auf den roten und blauen Kabeln auf ein grünes Kabel zusammen. Die Pakete aus den verschiedenen Systemen (Dante & dSNAKE) werden dazu von den Switches für den Versand auf dem grünen Kabel mit einem kleinen "Bapperl" (engl. "Tag", daher auch die Worte tagged und untagged) versehen, damit der andere Switch die Pakete beim Empfang auseinanderhalten kann. Abstrakt gesprochen bauen wir auf die physische Netzwerkstruktur - in der alle Geräte in einem gemeinsamen, physischen Netzwerk miteinander verbunden sind - eine logische Struktur oben drauf, in der es zwei getrennte, logische Netzwerke gibt. Pult, AR2412, Dante-Karte im Pult und der Rechner mit der DVS wissen nichts von dieser Abstraktion, da sie jeweils an einem "untagged"-Port hängen. Für sie sieht es so aus, als seinen sie direkt über die entsprechend farbigen Kabel mit ihrem jeweiligen Partner verbunden, also das Pult mit der AR2412 und die Dante-Karte mit dem Rechner.

Nach kurzer Durchsicht des Handbuchs sollte die oben gezeigte Konfiguration z.B. mit dem Netgear GS105E zu realisieren sein. Das stellt keine Empfehlung dar und ich schreibe deswegen "sollte", weil ich keine Ahnung habe, wie krepelig die zur Konfiguration notwenige Windows-Software ist und ich diese Switches selbst nicht habe.

Zitat von "Jan"

Ich denke nicht das VLANs etwas bringen, wenn der Switch nicht auf QoS kann um die VLANS zu priorisieren.

Was für ein QoS willst du denn machen? DiffServ? Ist Layer 3 und damit für dSNAKE nicht anwendbar, da das ein reines Layer 2-Protokoll ist. Manche Switches bieten ein Feature namens "Voice-VLAN". Aber sowohl dSNAKE als auch Dante sind nunmal beides Echtzeit-Anwendungen ohne den Luxus, senderseitig mal kurz anhalten zu können, daher müsstest du eigentlich beide gleich priorisieren und hast damit nichts gewonnen: Wenn Dante und dSNAKE die einzigen Gäste sind, bringen VIP-Ausweise für beide wenig, falls der Laden nur einen Barkeeper hat.

Bleibt also die Lösung mit "mehr Hubraum" übrig, sprich: die Verbindung zwischen den Switches muss einfach dick genug sein, um beide Datenströme ohne Einschränkung parallel transportieren zu können. Mit Gigabit-Ethernet ist das für die hier zu erwartenden Setups sicher gegeben. Wer jetzt noch Endstufen- und Funkstrecken-Remote, Medienserver, Artnet usw. über die gleiche Leitung machen will, kann das auch noch machen, Stichwort hier wäre dann 802.1p, damit kann man vereinfacht gesprochen verschiedenen VLANs verschiedene Prioritäten zuweisen. Beispielsweise: Dante- und dSNAKE-VLAN = wichtig, Artnet = weniger wichtig, Medienserver = noch weniger wichtig, Rest = am unwichtigsten. Für die allermeisten Aufbauten und das Personal vor Ort ist es aber sicherlich praxistauglicher, einfach ein zweites Kabel zu ziehen. Das kann jeder und es gibt keine zusätzlichen Geräte, die kaputtgehen oder falsch konfiguriert werden können.

Zitat von "mike j."

Version = v1.02, Tastatur = Logitech K120

Lustig, bei der GLD hier hat es mit eben diesem Modell nicht geklappt :cry: Hab meinen vorherigen Beitrag mit deiner Information korrigiert. War die Tastatur schon beim Hochfahren angeschlossen oder hast du die erst nachträglich angesteckt? Dem Kernel sollte das eigentlich egal sein, aber vielleicht ist die A&H-Software da wählerisch

Grüße
Joern

Zitat von "TWOsider"

Was für ein QoS willst du denn machen? DiffServ? Ist Layer 3 und damit für dSNAKE nicht anwendbar, da das ein reines Layer 2-Protokoll ist.

Ich arbeite seit 15 Jahren in der IT und wenn ihr sowas macht.. dSnake + Daten über ein Kabel, dann MUSS man entscheiden, welche Verbindung am wichtigsten ist, wenn es um Echtzeitkommunikation geht. Dante wird doch in diesem Szenario nur als Add-On benutzt. dSnake Überträgt die Musik-Daten zum Pult und wieder zurück und wenn 100Mbit/s bereits "knapp" sind, dann sollte dieser Kanal priorisiert sein. Die restlichen 900mbit/s bleiben dann für Dante übrig und das ist denke ich mehr als genug, denn die Bandbreite hängt von der Kanalzahl ab.

Man kann VLAN's priorisieren unabhängig vom darüber fließenden Traffic. Voice-VLANs sind eine fertige Klasse, die man nur einschalten brauch, aber auch so kann man sagen VLAN 2 liegt höher als VLAN 1 oder andersherum. Der Switch muss das natürlich können. Z. B. HP ProCurve oder DELL PowerConnect..

Es geht mir nur darum zu verhindern das Datenpeaks die dSnake Verbindung ggf. unterbrechen. Und ja ich denke dSnake wird keine Verzögerung dulden, denn wir sind hier im Live bereich.. hier wird nix gebuffert.. wäre ja schlimm wenn doch. Der Anspruch Zero-Latenz zieht sich durch alle Geräte im Livebereich durch. Ein paar Millisekunden sind immer gegeben, aber bei Netzwerken reichts wenn jemand von PC1 nach PC2 (verbunden über ein VLAN Trunk über mehrere Switche) eine Datei transferiert.. schwups ist alles andere Tot.

Wenn wir in der GLD Nutzungsklasse bleiben für eine VA, sehe ich persöhnlich auch kein Problem damit über VLAN 3 das ARTNET laufen zu lassen. Sicher eine praktische Sache.
Würd ich mir glatt zur GLD-080 noch nen Chamsys 4-Port ARNET Interface kaufen

Was genau habt ihr eigentlich mit Dante auf der Bühne vor?!? Find die Dante Karte fürs GLD ja schon ziemlich teuer..

Zitat von "mike j."

Was mir allgemein bei dem Digitalen Zeug immer ein Dorn im Auge ist: Bei einem normalen Analogmulticore, wenn eine Ader defekt ist, passiert bis auf einen Pegelabfall nichts. Oder es fällt ein (1) Kanal aus, oder 2. Bei den Digitalen ist gleich komplett aus, wenn was mit dem Kabel ist. Braucht ja nur wer einen Stuhl draufstellen oder ein Absperrgitter drauf oder oder oder... Macht es hier Sinn ein 2. Kabel mitzunehmen als Ersatz (kosten ja nicht die Welt) - wie schaun da eure Erfahrungen damit aus?

Da wir grad beim Thema mit der Switch Verkabelung sind. Mit einem Enterprise Managed Switch (so nenen ich sie mal, weil Layer3 nicht erforderlich ist.. Layer 2 Switche reichen). Kann man einfach zwei Ports koppeln und mit zwei Kabeln auf unterschiedlichem Wege FOH und Bühen verbinden. Nennt sich Porttrunking. Das kann man so einstellen, das es einen aktiven und einen passiven Port gibt oder das es Aktiv/Aktiv (doppelte Bandbreite) arbeitet. Fällt ein Kabel aus, merkt der Switch das und schickt die Daten über das andere Kabel.

In der Theorie geht das Transparent, in der Praxis hab ich in der Regel immer Verbindungsabbrüche gehabt. So lange sich die Geräte von allein wieder finden ist das kein Problem. Sollte das passieren, ist 2-3 Sekunden lang ruhe und dann gehts weiter. Viel schneller als ein Mensch auf beiden Seiten die Kabel umstecken könnte.

Zitat von "Jan"

[...] Fällt ein Kabel aus, merkt der Switch das und schickt die Daten über das andere Kabel.

Und genau hier liegt der kleine Schönheitsfehler in diesem Verfahren für die Anwendung "Audio-Netzwerk". Du meinst sicherlich 802.1ax (Link Aggregation Control Protocol, früher 802.3ad, je nach Hersteller auch mit den Begriffen Trunking, Bonding, Teaming, Bundling usw. bezeichnet). Switches, die entsprechend konfiguriert sind, schicken sich sog. LACPDU zu und "merken" dadurch, ob die Verbindung noch da ist oder nicht und schalten erst dann entsprechend um. Das Interval zwischen zwei solchen "Hello"-LACPDUs ist mindestens das Short Timeout von 3 Sekunden, d.h. wenn das Kabel kaputt geht, schaltet der Switch nicht sofort alles auf den anderen Link, sondern erst, wenn er nach drei Sekunden kein "Hello" bekommen hat. Dieses aktive "ich bin noch da" ist auch sinnvoll, denn wenn z.B. zwischen zwei Switches ein Teil der Strecke mit einem Medienkonverter auf Glasfaser überbrückt wird, merken die Switches sonst nicht wenn die Faser bricht, da die jeweilige Verbindung zum Konverter ja noch ok ist. Um sowas zu erkennen muss also ein aktives Verfahren über solche "Lebst du noch?"-Pakete zum Einsatz kommen.

LACP wird eingesetzt, um zum einen die verfügbare Bandbreite zwischen zwei Knoten durch Bündelung bestehender Verbindungen und damit ohne den Austausch von Hardware zu erhöhen und dabei gleichzeitig eine Redundanz zu schaffen, die gegenüber dem Ausfall einzelner Verbindungen des Bündels (mit einer kleinen MTTR) tolerant ist. Es ist auch nicht so, dass man durch das Zusammenschalten von zwei 100 MBit/s-Ports quasi einen 200 MBit/s-Port bekommt. Die Verteilung der Pakete auf die beiden Verbindungen geschieht nämlich nicht einfach abwechselnd "wo grade was frei ist" sondern pro Datenstrom. Wie ein Datenstrom definiert ist, hängt dabei vom auf dem Switch eingesetzen Algorithmus ab. Der Grund dafür ist, dass der Standard vorsieht, dass die Reihenfolge der Pakete in einem Strom nicht durcheinandergebracht werden darf und das geht nur, wenn alle Pakete die logisch zusammengehören nacheinander immer über dieselbe Verbindung geschickt werden.

Das Verfahren ist für "normale" Netzwerke auch sinnvoll, wo es primär um die Erhöhung der Bandbreite geht und eine kurze Unterbrechung durch weiter oben arbeitende Protokolle wie TCP ausgeglichen werden kann. Eine z.B. Dateiübertragung "hängt" kurz zeitlich, geht aber dann weiter. Beim Live-Ton ist in diesem Fall kurz Ruhe und die Aufnahme an dieser Stelle defektiös. Zugegeben, in den meisten Fällen läuft keine Aufnahme und ein kurzer Ausfall ist sicher zu verkraften, daher ist die Absicherung per LACP einem manuellen Umstecken was den Zeitfaktor angeht immer noch vorzuziehen, eine wirkliche Lösung wenn man keinen Ausfall dulden kann ist es aber nicht. Preislich redet man jetzt auch nicht mehr über die 30 EUR-Kategorie an Switch-Hardware sondern schon eher über 130+ EUR-Kategorie. Dazu kommt der nicht unwesentlich gestiegene Konfigurationsaufwand. Richtig bescheiden wird es, wenn aufgrund von welchen Umständen auch immer die Switches anfangen immer mal wieder zu glauben, einer der beiden Links tot sei und dann ohne ersichtlichen Grund (mit Unterbrechung) auf den Reserve-Link umschalten, nur um dann kurze Zeit später (wieder mit Unterbrechnung) zurückzuschalten. Wird dann ein Fall für den I don't need that-Thread ...

Die hier geforderte Redundanz für das Audio-Netzwerk will man also eher so haben, dass die Daten parallel immer über beide Verbindungen geführt werden. Quasi die True-Diversity im Empfänger wie man sie von Drahtlosanlagen kennt - nur eben für das Netzwerk. Der Empfänger verarbeitet den Datenstrom, den er "am besten" empfängt. Sowas bietet in dieser Form um bei A&H zu bleiben nur der große Bruder iLive (T) mit einer redundanten ACE-Verbindung zwischen Pult und MixRack. Oder eben MADI. So gesehen ist mein Satz zwei Beiträge weiter oben also auch nicht ganz präzise, ich muss ergänzen, dass die Netzwerk-Redundanz keinen nahtlosen Failover ermöglicht sondern dieser mit einer kurzen Unterbrechnung einhergeht, während der die in dieser Zeit gesendeten Audio-Daten mit einer gewissen Wahrscheinlichkeit verloren gehen.

Grüße
Joern

Joern,

du hast mit deinen Aussagen nicht unrecht.. aber sie treffen hier nicht so ganz zu.

1) LACP gibt es sowohl in passiver als auch in aktiver Form. Die passive sendet keine Pakete. Beide Links sind aktiv.. die Datenströme werden gemäß dem was du sagst aufgteilt. Fällt ein Kanal weg, sind die Datenpakete die grade übertragen werden sollten weg. Für eine Veranstaltung wo das Geld nur für ein GLD-080 reicht.. shit happens

2) LACP ist gar nicht erforderlich. Nimm die selbe Switchmarke, z. B. HP und Trunk die Ports einfach. Ist wesentlicih robuster als LACP, sendet auch keine Pakete und geschieht auf absolut unterste Ebene.

3) Bandbreiten verdoppelung ist hier gar nicht erforderlich und gar nicht sinn des Vorschlags von mir gewesen und ja es würde auch nicht funktionieren, weil der Datenstrom immer konstant ist (Audio), wie du bereits gesagt hast.

Letztendlich gibts noch die Möglichkeit zwei Kabel zu legen, an der Bühne beide einstecken am Switch (ohne spezielle Switch Einstellungen) und am FOH bei Bedarf manuell umstecken, wenn die Leine reißt.

Es driftet hier zunehmend in eine Netzwerk-Diskussion ab, will ich eigentlich nicht, aber soviel möchte ich noch sagen:

Zitat von "Jan"

[...] Die passive sendet keine Pakete. Beide Links sind aktiv.. die Datenströme werden gemäß dem was du sagst aufgteilt.

Schon klar das es den passiven Modus gibt. Aber: LACP auf den entsprechenden Switches an beiden Enden jeweils im passiven Modus zu betreiben ist nicht sonderlich sinnvoll oder? Denn so weiß ja keiner der Switches, das am anderen Ende der beiden Leitungen auch einer (und zwar derselbe) hängt und man die beiden Leitungen zu einer logischen zusammenfassen könnte, denn schließlich halten sich im passiven Modus beide über ihre Fähigkeiten bedeckt. In diesem Fall wird dann auch nichts aufgeteilt, denn ohne Wissen über die Anzahl der parallel nutzbaren Verbindungen geht das nicht. Und wenn beide Links ohne Bündelung (und ohne STP) aktiv sind, endet das spätestens mit dem ersten Broadcast (und dSNAKE sendet ausschließlich Broadcast) im Desaster. Also: Mindestens eine Seite muss schon im aktiven Modus betrieben werden, sonst wird keine Bündelung ausgehandelt.

Zitat von "Jan"

LACP ist gar nicht erforderlich. Nimm die selbe Switchmarke, z. B. HP und Trunk die Ports einfach. Ist wesentlicih robuster als LACP, sendet auch keine Pakete und geschieht auf absolut unterste Ebene.

Was ja nun nichts anderes ist, als die statisch konfigurierte und proprietäre Variante von LACP. Klar kann man das machen, hab ich auch nicht anders behauptet. "Robuster" ist das ganze auch nur deswegen, weil es fest konfiguriert ist. Und wenn der einfache Trunk keine "Hello"-Pakete sendet, sondern die Datenströme stumpf auf die Menge der konfigurierten Verbindungen verteilt, hat man spätestens bei der oben schon beschriebenen Adaptierung mittels Medienkonverter und Faserbruch ein Problem, diese Art von Fehler wird nämlich ohne aktive Überwachung nicht erkannt. Klar wird wahrscheinlich niemand seine GLD redundant per Glasfaser mit der AR2412 verbinden, aber in größeren Installationen mit anderen Pulten kann sowas schonmal vorkommen, daher hier die "Warnung" vor dieser Stolperfalle. 802.1ax funktioniert als Standard (hoffentlich) herstellerübergreifend.

Zitat von "Jan"

Bandbreiten verdoppelung ist hier gar nicht erforderlich und gar nicht sinn des Vorschlags von mir gewesen und ja es würde auch nicht funktionieren, weil der Datenstrom immer konstant ist (Audio), wie du bereits gesagt hast.

Weiß ich, dass das nicht der Sinn deines Vorschlags war Ich wollte auch nur herausstellen, dass der primäre Zweck von LACP nicht die Schaffung einer Redundanz sondern eher die Vergrößerung der Bandbreite ist. Wenn eine der physischen Verbindungen ausfällt, ist die logische Verbindung dadurch als positiver Nebeneffekt noch nicht völlig tot, aber eben nur noch mit weniger Bandbreite nutzbar, die aber hier für den Transport der Audio-Daten natürlich immer noch ausreicht.

Zitat von "Jan"

Letztendlich gibts noch die Möglichkeit zwei Kabel zu legen, an der Bühne beide einstecken am Switch (ohne spezielle Switch Einstellungen) und am FOH bei Bedarf manuell umstecken, wenn die Leine reißt.

Das ist eine gute Idee, die es dem Anwender ohne viel zusätzliche Hardware und vorallem ohne Konfiguration erlaubt eine Kabel-Redundanz herzustellen und im Fall der Fälle die Veranstaltung weiterzuführen, ohne sich einmal quer durchs Publikum quetschen zu müssen. +1 dafür :wink:

Grüße
Joern

Um nochmal zur "Tastatur-Problematik" zurückzukommen:

Mit einem "Microsoft Keyboard 200" funktioniert _nicht_:

die Kanalbeschriftung der Inputs

die Beschriftung von Scenes/Shows

Was hingegen funktioniert, ist während des Bootvorgangs ins BIOS zu gehen. Dort funktioniert die Tastatur ohne Probleme.

Softwareversion ist auch die 1.02.
Evtl. sind die GLDs mit unterschiedlicher "OS-Version" ausgestattet, die entweder support für eine angeschlossene Tastatur bietet oder nicht. Prinzipiell sollte das kein Problem darstellen, sofern A&H dazu gewillt ist.

Grüße
Mathias

Ein kleiner Erfahrungsbericht zum gld80.
Open Air Veranstaltung, mit einer Top40 Band die ich fest betreue.
Die Band hat fürs Monitoring ein eigenes. 01v96 auf der Bühne, per passivem Split geht es dann zum Foh.
Erste kleine Enttäuschung, es gibt keinen offline-Editor, kommt meiner Arbeitsweise nicht besonder entgegen. Normalerweise bereite ich immer alles im Vorfeld so gut es geht vor.
Eckfrequenzen der EQs schonmal in die grobe Richtung bringen, Compressoren grob einstellen allerdings erstmal mit hohem Threshold, Gates setzen mit niedrigen Thresholds, etc. halt alles was einem das Leben beim Job leichter macht.
Vor Ort finde ich ein flamm neues Gld und richte mir alles ein während die Band sich aufbaut.
Die Kiste erklärt sich soweit von selbst. Was mich direkt tierisch nervt, ist das Einstellen der Filtergüte, da man hierzu den Frequenzencoder drücken muss. Dabei verschiebt man dann gerne ungewollt die wieder die Frequenz.
Der Compressor tut direkt was er soll, beim Gate muss ich etwas suchen, bis ich dann herausfinde das die Range vom Werk auf 0dB steht.
Die Effekte klingen gut und lassen sich schnell editieren. Insgesamt findet man auch als nicht eingefleischter iLiver eigentlich alles was man zum Gelingen des Jobs braucht.
Die Haptik ist insgesamt OK, reißt mich aber auch leider nicht vom Hocker. Die Fader fühlen sich etwas billig an, das Touchdisplay reagiert gerade im Randbereich nicht immer beim ersten Druck.
Während des Jobs verclicke ich mich ein paarmal bei den selecttasten und arbeite so im falschen Kanal. Ich finde, für Rechtshänder die Anordnung des Channelstrips auf der linken Seite etwas ungünstig, da man so irgendwie immer am Bildschirm vorbei schaut.
Unbedingt empfehlen würde ich den Einsatz einer USV, der Gig war dann nämlich leider nach einem Stromausfall und dem Wiedereinschalten vor erst zu Ende, da das Netzteil im Pult gestorben ist vermutlich durch eine induzierte Überspannung gestorben ist.
Ich konnte die Show dann zum Glück über das Monitorpult der Band zu Ende mischen.

Gruß

Sebastian

Zitat von "hunterstudios"

Unbedingt empfehlen würde ich den Einsatz einer USV, der Gig war dann nämlich leider nach einem Stromausfall und dem Wiedereinschalten vor erst zu Ende, da das Netzteil im Pult gestorben ist vermutlich durch eine induzierte Überspannung gestorben ist.

Das kann man aber wohl kaum dem GLD anlasten. Bei sowas werden wohl so ziemlich alle Pulte dahinscheiden. Aber ich rate generell bei Digitalpulten zur USV, selbst wenn es nur eine billige Tisch-USV ist. Allerdings haben die billigen oftmals keinen Überspannungsschutz, das heißt "irgendeine USV" schützt vor sowas dann nicht zwangsläufig.

Jens

Zitat

Das kann man aber wohl kaum dem GLD anlasten. Bei sowas werden wohl so ziemlich alle Pulte dahinscheiden. Aber ich rate generell bei Digitalpulten zur USV, selbst wenn es nur eine billige Tisch-USV ist. Allerdings haben die billigen oftmals keinen Überspannungsschutz, das heißt "irgendeine USV" schützt vor sowas dann nicht zwangsläufig.

Das wollte ich auch nicht dem GLD anlasten, sondern nur einmal herausstellen, wie wichtig der Einsatz einer USV sein kann.
Ich habe es bist jetzt selbst noch nicht erlebt, dass ein Pult über den Jordan gegangen ist.

Gruß

Sebastian

tja, da ist dann wohl das netzteil beschädigt. reserve-netzteile sind in dieser klasse natürlich extrem rar, so dass man nach sowas durchaus mit einem veranstaltungsabbruch rechnen muss.
gegen sowas kann eine USV durchaus helfen.
ich betreibe z.b. meine iLive grundsätzlich mit USVs!

Zitat

Zum Recordpegel: Ich habe den Master mitgeschnitten. Der war am Pult mit +6dB bei Peaks zu sehen. In dem File liegt der Peak bei -16dB.

Da bin ich jetzt auch drauf reingefallen.

Zu der "Recordin Matrix" - wie kann ich denn am einfachsten einen Live-Mitschnitt einrichten?
So daß ich noch 1-2 Ambience-Mics dazu mische.
Welche Routings muss da einstellen?

Und: ist es richtig, daß die DCA-Gruppen-Fader keine Aussteuerungsanzeige haben?
Ich kann da gerade keinen Sinn drin sehen?

PS: gerade gesehen, die Firmware 1.1. ist raus, soll das ME Personal Mixing System unterstüzen und demnächst gibt es wohl eine Ipad-App

Natürlich haben die DCA-Gruppen-Fader keine Aussteuerungsanzeigen. Das sind ja keine Subgruppen, wo alle Signale der Gruppe zusammengemischt werden, sondern nur eine Regelung. Den DCA-Fader auf -10dB zu stellen, ist das Gleiche als wenn du alle Fader der Gruppe um 10dB verringerst. Mit anderen Worten: Die DCA-Gruppe kennt nicht die Signalpegel der einzelnen Kanäle, kann sie demnach auch nicht anzeigen.

Zitat von "wora"

tja, da ist dann wohl das netzteil beschädigt. reserve-netzteile sind in dieser klasse natürlich extrem rar, so dass man nach sowas durchaus mit einem veranstaltungsabbruch rechnen muss.
gegen sowas kann eine USV durchaus helfen.
ich betreibe z.b. meine iLive grundsätzlich mit USVs!

Kannst Du mir freundlicherweise den Typ der USV nennen?

Wenn ja dann vielen Dank

Grüße der Andy

ich nutze nun seit jahren USVs von Roline. die genauen typen habe ich nicht im kopf.

djobi:
eine DCA gruppe simuliert die früher in analogpulten benutzten VCA gruppen.
diese generieren lediglich eine steuerspannug zur pegelkontrolle der für die jeweilige gruppe ausgewählten einangskanäle
es läuft also kein audiosignal über die DCA, somit kann hier auch kein pegel angezeigt werden.

Das Problem ist mit dem Recorder das dieser Full Scale arbeitet. Da er ja Digital am Bus hängt. Heißt um die Aufnahme gut Auszusteuern muss der Bus gut Pegel haben.

Mit dem VCA neigt man aber er dazu zu wenig Pegel in den Main zu geben. Weil wie schon festgestellt man die Summe aus dem VCA Pegelmäßig nicht sieht. Dazu kommt das man wissen muss das zwischen den +6db und dem Peak gewaltig Luft ist.

Ich habe jetzt keine Patentlösung wie man genug Pegel mit einen VCA erzeugt aber vielleicht können andere Kollegen ein paar Tips geben.
Um den Pegel vom Recorder anzuheben ziehe ich den Regler in der Matrix etwas hoch.

Die Ambience-Mics werden in die Matrix geroutet und dann dem Recorder zugemischt. Wie das muss ich selber erst mal ausprobieren. Da ich ja über Dante Recorde.