Das Handy als Pult: wofür das gut ist und warum der Server in der Anwendung wohnt

Das Hauptproblem des Lichtoperators passt in einen Satz: Er sitzt nicht dort, wo das Publikum hinschaut.

Am Pult haben Sie Ihren Blickwinkel, Ihre Augenhöhe, Ihre Reflexe auf dem Monitor. Ein Gegenlicht, das vom Pult aus in Ordnung aussieht, blendet den Zuschauer in Reihe sechs. Ein Wash, der im Visualisierer gleichmäßig aussieht, sammelt sich auf der Bühne in Flecken. Um das zu sehen, muss man aufstehen und weggehen — und in diesem Moment ist niemand am Pult, der GO drückt.

Daher die Weboberfläche: Ein Handy im selben Netz öffnet eine Seite und tut das, wofür Sie sonst zum Laptop zurückgingen.

Die Szenarien, für die man das einrichtet

Prüfen aus dem Saal. Sie gehen durch die Reihen, fahren unterwegs Cues und schauen, wie es von den Plätzen aussieht. Ohne das wird das Einrichten von Winkeln und Pegeln zum Staffellauf: fünf Schritte hin, fünf zurück, und das vierzigmal.

Einrichten von der Bühne aus. Sie stehen unter dem Gerät, wählen es am Handy, ziehen die Intensität hoch — und sehen den Fleck dort, wo Sie stehen, statt über eine Kamera.

Eine zweite Person beim Durchlauf. Die Assistenz fährt GO nach Textbuch, Sie korrigieren Pegel. Oder umgekehrt.

Aufbau. Blackout vom Handy, wenn die Bühne sofort dunkel sein muss und Sie auf der Leiter stehen.

Das Pult bleibt beim Operator. Das Handy ist kein Ersatz, sondern eine zweite Hand.

Von innen: warum SSE und keine Websockets

Eine technische Entscheidung, die erklärt gehört, weil sie kontraintuitiv ist.

Daten fließen hier in beide Richtungen: nach unten zum Handy der Zustand (aktiver Cue, aktive Presets, Masterposition), nach oben die Befehle. Der Reflex sagt: bidirektionaler Austausch, nimm einen WebSocket.

Wir haben nach unten Server-Sent Events genommen und nach oben ganz normale POSTs — aus folgendem Grund.

Nach oben fliegen Fingertipps, im lebhaftesten Fall ein paar pro Sekunde. Für diesen Verkehr ist ein POST nicht schlechter als ein WebSocket-Frame, und man kann ihn mit curl debuggen.

Nach unten fließt Zustand, und er fließt ausschließlich nach unten. SSE ist buchstäblich eine HTTP-Antwort, die nicht endet: Der Server hält die Verbindung offen und schreibt Zeilen nach. Kein Framing, kein Handshake, kein Ping-Pong, um herauszufinden, ob der Client noch lebt.

Der Preisunterschied: Ein WebSocket in Node bedeutet entweder eine externe Abhängigkeit oder eine eigene Implementierung von RFC 6455 samt Framing und Maskierung. SSE ist ein res.write() in einer Schleife. Für die Funktion „dem Handy zeigen, welcher Cue aktiv ist" ist Letzteres ehrlicher.

Nebengewinn: SSE verbindet sich selbst neu. Das Handy ist eingeschlafen, das WLAN hat gezuckt — der Browser stellt den Strom ohne eine einzige Zeile unseres Codes wieder her. Beim WebSocket hätten wir das von Hand geschrieben — und mit Fehlern.

Der Zustand geht mit 120 ms Throttling und Deduplizierung raus: Während der Operator einen Fader zieht, fliegen nicht bei jedem Frame Snapshots.

Befehle nehmen denselben Weg wie MIDI und OSC

Das ist Prinzip. Das Handy bekommt keinen eigenen Weg in den Zustand der Anwendung: Sein Befehl läuft durch denselben Dispatcher wie ein Pad-Druck auf einem MIDI-Controller oder eine OSC-Nachricht vom Tablet.

Das Motiv ist pragmatisch: Drei parallele Wege zu einer Aktion bedeuten drei Sätze Fehler und drei Stellen, an denen jemand vergessen hat, die Logik nachzuziehen. Ein Weg, ein Satz.

Der HTTP-Server selbst wohnt im Hauptprozess der Anwendung, neben DMX und OSC. Das Interface-Fenster öffnet überhaupt keine Ports.

Zur Sicherheit: die PIN ist keine Deko

Der Server hört auf allen Netzwerkschnittstellen — sonst käme das Handy nicht durch. Das heißt: Das ganze Netz der Spielstätte sieht ihn.

Stellen Sie sich vor, was das bei einem Konzert bedeutet: ein Gäste-WLAN mit dreihundert Leuten und eine offene Seite mit einer Blackout-Taste. Böse Absicht braucht es dafür nicht — Neugier und eine zufällig erratene Adresse wie 192.168.1.42:7331 genügen.

Deshalb:

• Setzen Sie eine PIN. Eine leere PIN bedeutet „jeder in diesem Netz darf rein", und die Einstellungen warnen ausdrücklich davor. Mit PIN bekommt das Handy ein Sitzungs-Cookie (HttpOnly, 12 Stunden) — Sie müssen sie nicht ständig neu eingeben.
• Brute Force wird abgeschnitten: mehr als zehn Versuche pro Adresse und Minute, dann ist Schluss. Eine vierstellige PIN sind zehntausend Versuche, bei diesem Limit also siebzehn Stunden statt einer Minute.
• Ein PIN-Wechsel wirft alle raus. Die Assistenz ist mit ihrem Handy gegangen — PIN ändern, und ihre Sitzung stirbt mit den anderen.

Ideal wäre natürlich ein eigenes Show-Netz, in das Fremde gar nicht kommen. Aber weil wir wissen, dass es in der Realität einen Switch für alles gibt, ist die PIN nicht ohne Grund standardmäßig aktiv.

Verbinden — und die Kleinigkeit, die alles verdirbt

In den Einstellungen stehen die Adresse und ein QR-Code: Kamera drauf halten, statt eine IP im halbdunklen Saal einzutippen. Spart dreißig Sekunden und einen Tippfehler.

Öffnet sich die Seite nicht, liegt es fast immer an der Client-Isolation: Gäste-WLAN ist häufig so konfiguriert, dass sich Geräte gegenseitig nicht sehen. Sofort geprüft — Handy und Laptop müssen sich anpingen können.

Und das Ärgerlichste, das man vorher erledigen sollte: Bildschirmsperre ausschalten. Das Handy geht genau dann aus, wenn GO gedrückt werden muss — und Sie entsperren es einhändig auf der Leiter.