Warum das Replizieren des Lichtengine-Zustands eine schlechte Idee ist, was ein Frame-Spiegel besser macht, warum die Showposition getrennt reist und warum die Rückgabe der Kontrolle Handarbeit bleibt.
Die Aufgabenstellung klingt einfach: Es soll einen zweiten Rechner geben, und wenn der erste stirbt, bleibt das Licht an.
Dann beginnt die Technik, und schon die erste Entscheidung bestimmt, ob Sie ein funktionierendes Schema bekommen oder ein hübsches, das im ungünstigsten Moment versagt.
Der naheliegende Gedanke: Synchronisieren wir doch den Zustand. Das Backup-Pult hält dieselben Cues, dieselben Effekte, dieselbe Position — und rechnet bei der Übernahme einfach weiter.
Das ist eine Falle, und zwar aus folgendem Grund.
Eine Lichtengine ist kein Wertespeicher, sondern eine Maschine, die das Bild in jedem Frame neu berechnet: Effekte mit ihren Phasen, Fades mit ihren Zeiten, Ebenen paralleler Cue-Listen, Grandmaster. Damit das Backup „einfach weiterrechnet", müsste es nicht die Daten reproduzieren, sondern die Ausführungsphase: in welcher Millisekunde ein Fade steckt, bei welchem Winkel der Regenbogen-Sinus sitzt, welche Ebene welche überschreibt.
Das übers Netzwerk zu synchronisieren heißt, eine zweite Lichtengine zu schreiben, die im Protokoll lebt. Und diese zweite Engine wird zwangsläufig auseinanderlaufen: Hier geht ein Paket verloren, dort kommt ein Tick 3 ms zu spät, und die Abweichung sammelt sich genau bis zu dem Moment, in dem sie nicht hätte sein dürfen.
Das Ergebnis-Frame. Das Hauptpult schickt dem Backup zehnmal pro Sekunde seinen Ausgabepuffer — exakt die Bytes, die an die Geräte gehen. Keine Mechanik, keine Phasen: das Bild, wie es ist.
Das Backup gibt es nicht aus. Es schweigt — kein einziges Byte über USB oder Netzwerk — und merkt sich lediglich das letzte Frame. Bei der Übernahme stellt es dieses Bild und lebt anschließend mit eigener Logik weiter.
Die Übernahme wird ehrlich, ganz ohne gemeinsames Modell. Das Publikum sieht genau das Bild, das einen Sekundenbruchteil vor dem Tod des Hauptpults bestand — weil wir übertragen, was das Publikum sieht, und nicht das, woraus es berechnet wurde.
Der Herzschlag läuft getrennt, viermal pro Sekunde. Stille länger als zwei Sekunden (acht ausgefallene Schläge) löst die Übernahme aus. Die Schwelle ist einstellbar, unter eine Sekunde zu gehen ist jedoch unklug: Ein Netzwerkpeak beim Content-Upload liefert einen Fehlalarm, und zwei Pulte, die gleichzeitig auf die Linie schreiben, sind schlimmer als eine Sekunde Verzögerung.
Das Bild ist übertragen. Aber stellen Sie sich vor: Das Hauptpult stirbt bei Cue 47, das Backup übernimmt, das Licht stimmt. Der Operator drückt GO — und landet bei Cue 12, weil das Backup den ganzen Abend dort stand.
Deshalb reist neben dem Bild die Showposition: aktive Cue-Liste und Cue darin, Grandmaster, Blackout, Freeze. Sie wird im Moment der Übernahme angewendet — und zwar ohne den Cue erneut zu fahren. Das Licht stimmt bereits; ein erneuter Start schenkte dem Publikum ein zusätzliches Fade.
Das sind zwei verschiedene Datenströme, sauber getrennt: „was auf der Bühne ist" und „wo wir in der Show sind".
Der häufigste Anfängerfehler: in jeden Rechner ein USB-DMX-Interface und beide auf eine Linie führen.
Das geht nicht. RS-485 ist ein Bus, auf dem zu jedem Zeitpunkt genau ein Sender spricht. Zwei Interfaces, die gleichzeitig schreiben, kämpfen physikalisch um den Pegel auf der Doppelader; eine Arbitrierung sieht DMX512 überhaupt nicht vor. Das Ergebnis ist nicht „der Letzte gewinnt", sondern Müll auf der Linie und zuckende Geräte.
Es gibt genau ein funktionierendes Schema: beide Pulte geben das Licht übers Netzwerk aus (Art-Net oder sACN) auf gemeinsame Nodes. Das Backup schweigt im Netz, der Node sieht also einen einzigen Sender — kein Kampf, keine Arbitrierung nötig.
Wer trotzdem auf USB setzt, bekommt aus der Redundanz nur einen schnellen manuellen Neustart: Interface aus dem toten Rechner ziehen, in den lebenden stecken. Auch das ist ein Plan — aber einer, den man probt und nicht entdeckt.
Das Hauptpult lebt wieder. Das Backup hört es — der Herzschlag ist zurück. Und tut nichts.
Eine automatische Rückgabe gibt es bewusst nicht. Der Moment, in dem das Hauptpult „schon lebt", aber noch die Show lädt oder das Interface neu öffnet, ist im Netzwerk nicht von dem Moment zu unterscheiden, in dem es bereit ist. Die Automatik gäbe die Kontrolle in der ersten Sekunde zurück — und Sie bekämen entweder ein Loch oder zwei Sender gleichzeitig.
Also gibt ein Mensch zurück: Wer sich überzeugt hat, dass das Hauptpult wirklich da ist, drückt am Backup „Kontrolle zurückgeben". Ein Knopf, dafür in einem sinnvollen Moment.
Laufende Effekte und ein unvollendetes Fade laufen nach der Übernahme nicht weiter. Das Backup übernimmt das letzte Frame, wie es ist — statisch. Starb das Hauptpult genau in der Mitte eines Zehn-Sekunden-Fades, kommt dieses Fade nicht an: Das Bild bleibt dort stehen, wo es erwischt wurde.
Das ist die direkte Folge der Entscheidung „wir übertragen das Ergebnis, nicht die Mechanik", und ich würde sie nicht ändern: Ein statisch richtiges Bild ist besser als ein desynchronisiertes bewegtes.
Die Showposition wird trotzdem übertragen, der nächste GO geht also dorthin, wohin er auch am Hauptpult gegangen wäre, und das Fade in diesen Cue läuft normal.
Der Frame-Spiegel schaltet sich übrigens bei Anlagen mit mehr als 64 Universen nicht ein: Dort wächst der Datenverkehr schneller als der Nutzen. Der Herzschlag läuft weiter — das Backup übernimmt, beginnt aber mit dem eigenen Bild.
Schritt vier wird am häufigsten übersprungen — und dann erfährt man vom Problem an dem Abend, an dem das Hauptpult tatsächlich ausfällt.