Meet the Visualiser

The fourth role is the quietest of the four, and the easiest to overlook. A Visualiser is a passive snooper — it listens to the show but never outputs anything physical, never changes anything, never has any authority to do anything that affects the rig.

Think Capture, WYSIWYG, Depence, or the preview window inside a console. Anything that watches the lighting network in order to render what's happening, but doesn't drive a DMX socket, falls into this role.

What a Visualiser can do

A Visualiser is allowed to subscribe to four kinds of stream:

Live levels (TID_LEVEL). Whatever the Senders are pushing onto the universes, the Visualiser sees in real time. That's how the previs window stays in sync with the actual rig.

Priority (TID_PRIORITY). So the visualiser can render the merge correctly when multiple Senders are fighting for the same channels. If the previs shows the wrong thing, you want to know before the show, not during it.

Preview (TID_PREVIEW). This is a separate stream from the live levels — a "blind" feed that some consoles emit so you can pre-cue and previs without affecting the rig. It goes to a different multicast address from the live data, so a physical Node never accidentally outputs it.

Universe announcements (TID_UNIVERSE). When a Sender starts streaming universe 5, it broadcasts a "join" notification. The Visualiser listens for these and dynamically joins the matching multicast group. When the Sender stops, the Visualiser leaves cleanly. No manual subscription management.

The Visualiser also takes part in the discovery process. It hears every poll, replies with its own identity, and shows up in the Manager's table of devices like any other piece of kit. It can read all the standard status TIDs to populate its UI with rig health.

What a Visualiser can't do

This is the interesting bit, and it's enforced cryptographically rather than by polite agreement.

A Visualiser is given the Sender Key (Ks) and the Citizen Key (Kc), but never the Manager keys (Km_global or Km_local). That means even if a Visualiser is compromised — somebody slips malware into the previs PC — it has no mathematical way to forge a Manager command. Any packet it tries to send to the management URI will fail HMAC verification at the fixture and be silently dropped.

It also cannot send level data. It has the receive half of the Sender Key but, by convention and by role definition, it doesn't generate output traffic. (And in practice, sender mandate-rules in the spec mean a real visualiser product wouldn't even have a way to.)

Why this matters

Two reasons. First, it lets you put a previs PC, which is often a Windows or Mac machine with a browser, an email client and various other softwares, on the show network without lying awake worrying about it. Second, it gives manufacturers a clean role to map their visualiser products onto — they don't need a special "trust this app" workaround, the role just exists.

Now that the cast of roles is introduced, the next post tackles the bit that actually makes Sig-Net different from sACN: the keys, and how a device joins the network in the first place.

This series is based on v0.20 of the Sig-Net spec - visit Sig-Net.net for any updates.