Open Sound Control
A flexible message format for control and glue between systems, with no standard port, no discovery and no shared schema.
What it is
Open Sound Control is a message format rather than a transport or an application protocol. A message has a URL-like address pattern and a list of typed arguments, and messages can be grouped into bundles with a time tag. It is commonly carried over UDP and sometimes over TCP with framing. What OSC deliberately does not define is the thing people expect it to define: there is no standard port, no discovery mechanism, and no shared vocabulary of addresses. Every device publishes its own address space and its own argument types. In show systems OSC is the general-purpose glue, used for cue triggering, transport control, parameter changes and passing state between systems that share no other language.
Why it matters
OSC's flexibility is why it ends up everywhere, and why it becomes the least documented layer of a show system. A rig accumulates a web of point-to-point OSC connections built during tech to solve immediate problems, each one obvious to whoever built it, none of them written down. Months later a device is swapped, its address changes, and something stops working for reasons nobody can trace. The protocol offers no help here: without discovery, the destination list exists only where someone wrote it, and without a schema, the address map is only as good as the documentation. Treating OSC connections as documented signal paths rather than as configuration is what makes them survive a run.
No standard port and no discovery: the address map and destination list are show paperwork, not defaults
Argument types matter; sending an integer where a float is expected is a common and quiet failure
OSC over UDP is fire and forget; state that must arrive needs a transport or handshake that confirms it
Pattern matching in addresses can fan one message out to several targets, intentionally or otherwise
Can OSC carry tracking data?
Technically yes, and several systems offer it, but there is no standard schema for position in OSC, no defined timing model and no convention for units or coordinate handedness. That makes every such link bespoke and undocumented by default. It is a reasonable fallback when it is the only path between two systems, and a poor first choice when a protocol designed for position data reaches both ends.
UDP or TCP?
It depends on what the message means. Continuous parameter streams suit UDP, where a dropped packet is superseded almost immediately and delivery overhead is not worth paying for. Discrete state changes such as a go, a mode switch or an arm command suit a transport that confirms delivery, because a single lost message leaves two systems disagreeing with nothing to correct it. Many implementations support both, so choose per link.
How do we keep OSC from becoming undocumented glue?
Hold one table of every OSC path in the system: source, destination, port, address pattern, argument types and what the message is for. Keep it in the same package as the network documentation, and update it when a link is added during tech, which is when the temptation to skip it is highest. Anything that cannot be described in that table probably should not be in the show.