showstack

GitHub
Free forever·no account, no tracking, no third-party requests ·open data, free API
showstack / compare / osc-vs-midi-show-control

OSC vs MIDI Show Control

Should show control run on OSC or MSC? Below is every field we hold on both, side by side. Each one is sourced on the individual entry, and anything nobody could source is left blank rather than guessed.

Side by side

OSCMIDI Show Control
Categoryshow-controlshow-control
FlowControl — small, urgent, must arriveControl — small, urgent, must arrive
PortsUDP 53000, TCP 3032, TCP 3037
Transportudp, tcpmidi-din, usb
Multicastnono
Spec availabilityopen-publishedopen-published
StewardCNMAT, University of California BerkeleyThe MIDI Association (MIDI Manufacturers Association)
First published20021991
Statuscurrentcurrent
Our confidenceverifiedreported

Both are control flows. Latency and loss on the messages that fire once. A repeating level survives a dropped packet; a GO does not. That applies equally to either, so it is not a discriminator here.

Speaks both (20)

These are the safe choices if you have not committed to either, or need to bridge the two.

OSC only (79)

MIDI Show Control only (3)

What goes wrong with OSC

OSC defines no port and no transport. Every product picks its own, and the receiver usually needs telling the reply port as well as the listen port, so a link that "works" one way often has no return path at all.
Over TCP or serial there are two incompatible framings. OSC 1.0 prefixes each packet with a 32-bit length; OSC 1.1 uses SLIP. ETC put them on separate TCP ports (3032 and 3037) precisely because you cannot detect which is which.
There is no formal 1.1 specification document, only a NIME 2009 paper. When a datasheet claims "OSC 1.1 support" it can mean SLIP framing, the new argument types, or almost nothing.
Address patterns support wildcards on the receiving side, so a stray /eos/chan/* reaches far more than one channel. Test pattern messages against a rehearsal state, never against a running show.
Bundle time tags are 64-bit NTP timestamps and assume the two machines agree on time. Many entertainment implementations ignore the tag entirely and execute on arrival, so do not build sample-accurate timing on it.
UDP has no delivery guarantee and OSC adds none. A single lost GO is simply gone with no error anywhere. If the cue matters, use a TCP link where the product offers one.

What goes wrong with MIDI Show Control

The message is F0 7F <device_id> 02 <command_format> <command> <data> F7. Device ID 127 (0x7F) is all-call, so a receiver left at 127 acts on every message on the line including ones meant for another department.
Command format is a category, not an address. 01 is Lighting (General), 02 Moving Lights, and a receiver only acts on the formats it is set to accept. A format mismatch is the most common cause of "MSC is doing nothing".
Cue data is ASCII digits with 0x00 delimiters between cue number, cue list and cue path. Cue 5 and cue 5.0 are different byte strings, so cues can fire on some numbers and be silently ignored on others.
Nothing acknowledges an MSC message. If the receiver was powered down, on a different device ID or on the wrong command format, the sender reports a perfectly successful GO.
A DIN MIDI line runs at 31.25 kbit/s and everything shares it. A continuous MTC quarter-frame stream on the same cable will delay cue messages by a measurable and variable amount.
MSC is one-directional and has no state. A receiver that missed the GO will not catch up, so a device that came back from a reboot mid-act stays where it was until you send it somewhere.

Sources

Disagree with any of this?

Every claim above comes from one of the two entries and carries a source. If one is wrong, correcting it is a single file and it fixes this page automatically. Edit OSC or edit MIDI Show Control.