Meet the Sender

If the Manager is the brain, the Sender is the voice. It's the role that actually streams the show — DMX levels, priorities, sync triggers, timecode, and the announcements that tell the rest of the network what universes are live.

Anything that generates control data is a Sender. The playback engine inside a lighting console is a Sender. An architectural wall plate is a Sender. A media server pumping out pixel data is a Sender. A DMX gateway with input ports — receiving physical DMX and turning it into network traffic — is also a Sender, even if it's also playing the role of a Node on its output ports.

What a Sender actually streams

The bread-and-butter is TID_LEVEL: up to 512 channels of DMX slot data, multicast to a universe-specific address. Senders default to 44 frames per second, the same as standard DMX, but they can be pushed to 60, 120 Hz or higher for fast SPI pixel-tape work.

Alongside the levels, a Sender can stream TID_PRIORITY — per-slot priority values from 0 to 200. This is the same idea as sACN priority but with a useful twist: instead of one priority per universe, you can give every channel its own. That means a single backup desk can take over only specific channels of a specific universe rather than the whole stream.

A Sender can also fire TID_SYNC: a tiny zero-byte trigger packet that tells every receiving Node "output your buffered levels NOW, all together". This is what eliminates tearing on multi-universe pixel work — fifty universes of LED tape can all change their look on the same network frame.

For show-driven cues, a Sender can stream TID_TIMECODE in MIDI Timecode format, at any of the standard frame rates (24, 25, 29.97, 30, 48, 50, 59.94, 60, 100, 119.88, 120 fps). Up to 255 independent timecode streams can run side by side on the same network, so you don't have to fight your colleagues for time slot 1.

Polite streaming behaviour

Sig-Net Senders are designed to be gentle on the network. While levels are actively changing, the Sender transmits flat-out. As soon as values stop changing, it sends three identical packets (so any node that joined late catches the final state), then drops back to a 1 Hz keep-alive — a single packet per second carrying the current look. That keep-alive is what lets a node booting up mid-show synchronise to whatever's already on stage.

Senders prefer multicast for everything, because that's what makes the whole "snoop, merge and visualise" ecosystem work. They can unicast directly to one specific Node's IP address, but it's actively discouraged: it breaks merging, it breaks visualisation, and it removes Sig-Net's bandwidth advantage.

On a network that mixes Secure and Open Mode Nodes patched to the same universe, a Sender may optionally dual-cast — sending each level packet twice, once with the cryptographic signature and once unsigned — so both populations are served from the same stream without the Open Mode gear missing out.

TID_UNIVERSE — the polite-roommate announcement

There's one more Sender duty worth knowing about. Every five seconds, a Sender broadcasts a TID_UNIVERSE announcement listing every universe it's currently sending. Visualisers and other passive listeners use these announcements to dynamically join and leave the right multicast groups, so they only ever subscribe to streams that are actually live.

When a Sender starts a new universe, it announces a "join". When it stops, it announces a "leave". The whole system stays self-cleaning.

Next post: the Node — the role that actually does the work of turning Sig-Net into light.

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