DMX512: the old standard that is going nowhere
DMX512 dates from 1986 and carries 512 channels down a single cable. Each channel is a number from zero to 255. One fixture uses a few of them: dimmer, red, green, blue. Those 512 channels together are called a universe.
It is deliberately dumb: there is no feedback, no addressing, no check that the packet arrived. The sender shouts all 512 values 44 times a second, and whoever is listening listens. That sounds primitive and is exactly why it has worked for forty years.
The limitation is the cabling. One universe is one chain of devices, and you have to physically pull that chain through the building. Two universes means two chains.
Art-Net and sACN: DMX over the network
Art-Net and sACN both solve the same problem: the same DMX data, but over an ordinary ethernet cable. Instead of a chain through the building you lay one network, and put a node near each group of fixtures that turns it back into DMX.
The difference between the two is mostly origin and network behaviour. Art-Net is older and traditionally broadcasts across the whole network, which becomes noticeable on a large one. sACN (formally E1.31) uses multicast, so devices subscribe only to the universes they need.
In practice: with one network and a handful of nodes it makes no difference. Once it gets bigger, or shares the network with other equipment, sACN is the quieter choice. Both belong on their own VLAN, not on the building's guest wifi.
OSC: the language between software
Open Sound Control is not a lighting protocol but a message format. You send an address and a value: /room/scene/start with a 1 behind it, or /volume/bar with 0.4. That can be a number, a string, or several at once.
That makes it precisely what DMX is not: readable, flexible and not limited to 512 channels of zero to 255. Media servers, audio software, QLab, show control and Bitfocus Companion all speak it.
The downside is that there is no standard for the addresses. Every device invents its own names, so you need the manufacturer's documentation. And OSC usually rides on UDP: sent is not the same as arrived. For a cue that genuinely matters we build in a feedback path rather than hoping.
MIDI and SMPTE: when timing is sacred
MIDI comes from the music world and in show work is mostly used to send a button press on one device to another. Simple, reliable, and over short distances still perfectly good.
SMPTE timecode is something else: a continuous clock, hours-minutes-seconds-frames, that multiple devices follow. If light, sound and video genuinely have to land on the frame across a twenty-minute show, riding a shared timecode is more reliable than starting everything separately and hoping it stays together.
Modbus, Profinet and just a contact
The moment something mechanical happens you enter the world of industrial automation. Modbus and Profinet are the protocols you use to talk to a PLC: read positions, set outputs, fetch faults.
And then there is the simplest of all: a dry contact. Two wires that touch or do not. No addressing, no firmware, no network. For an emergency stop, a door contact or a start button that is still the most reliable signal there is, and it will stay that way.
A good system mixes them: OSC to the media server, sACN to the lighting, Modbus to the PLC and a contact to the button by the door.
What goes wrong in practice
The network. Art-Net and sACN on the same network as the till, the wifi and the cameras works for a while and then one day does not. Show traffic belongs on its own VLAN with equipment that handles multicast properly.
Static IP addresses nobody wrote down. A node that comes back on a different address after a power cut is a group of fixtures that does not work and nobody who knows why.
Universes used twice. Two sources transmitting on the same universe gives flickering light you can spend a day chasing.
And the classic: a closed system in the chain with no control interface at all. You hear that from us before you order it, not after.
Which one should I choose?
Usually not one. The question is not which protocol is best, but which protocol is spoken by the device you want to drive. Lighting does DMX, over the network as sACN. Software does OSC. Machinery does Modbus or a contact.
What is a real choice: making sure everything is driven by one system instead of four separate ones. That is show control, and it is the reason the protocols underneath do not have to matter to you.
What show control actually is →
To the relevant pages
