OSC – Open Sound Control

MIDI (Musical Instrument Digital Interface) was released in 1983. It is a technical standard that describes a communications protocol, digital interface, and electrical connectors that connect electronic musical instruments, computers, controllers and related audio devices for playing, editing and recording music.

MIDI is useful in live event production – for example, lighting desks will receive MIDI timecode to play out a light show, and MIDI triggers are used to fire off effects, change sound desk scenes and so on.

MIDI does however have limitations. It really was designed for the purpose of controlling electronic musical instruments, not production equipment, and it is nearly forty years old. Therefore, the commands available are limited, and the resolution for most things is limited to 127 steps.

You might think 127 steps is enough but quite often it is not. For example, say you were controlling a PTZ camera’s pan with a MIDI controller. The typical pan in a camera is 350º. That means the single smallest movement you can do is nearly 3º (350º divided by 127).

You simply cannot control the camera smoothly with such poor resolution.

Lastly, MIDI was not really designed for use over IP networks, so third-party apps have to take care of this, which occasionally leads to compatibility problems.

Enter Open Sound Control, otherwise known as OSC. Developed by the UC Berkeley Centre for New Music and Audio Technology and released in 2002, OSC introduced a robust communications method to remotely control media and other digital processes.

OSC is built on the User Datagram Protocol (UDP) networking protocol. Before we get further, I should explain the difference between UDP and TCP.

User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) are both core components of the internet protocol suite. The primary difference between UDP and TCP hinges on the fact that TCP requires
a three-way handshake when transporting data.

The sender asks the receiver to start a connection, the receiver responds, and the sender acknowledges the response and maintains a session between either end.

For this reason, TCP is reliable and can solve issues of packet loss and ordering. If a packet goes missing, it is re-sent because both ends know what has made it through successfully through error checking.

UDP, on the other hand, starts without requiring any handshake. It pushes out data regardless of any bandwidth constrains, making it speedier, but riskier.

Because UDP doesn’t support retransmissions, packet ordering, or error-checking, there’s potential for a network glitch to corrupt the data en-route. The main benefit for UDP is that the data gets to the receiver/s much more quickly because no handshaking is required.

Most streaming protocols are UDP. This means that OSC applications can send data using UDP to other hosts on an IP network without prior set-up of specific channels or paths, making OSC inherently networkable and so very easy to use via local networks and the Internet.

If you want to update yourself on show networks, check out my article in CX118 (link below).

With OSC you can transmit multiple data types. It uses a human readable, URL-style address format and can send data in forms of words or numbers. OSC also includes a picosecond-resolution timestamp, down
to 0.000000000001 of a second, which is more than adequate for live events.

The data transfer rate of OSC is only limited by your networking hardware and comfortably sits on Gigabit networks.

A great advantage of OSC is that there is no overall fixed scheme to define or restrict the set of possible messages, which is the case with MIDI. A second advantage is that older protocols can be easily translated to and from OSC.

Finally, OSC messages are self-descriptive. Just by looking at the text of a message, you can tell what it is for.

So, for example where a note-on MIDI message is a cryptic series of numbers: 1001 0011–0100 0101–0100, an equivalent OSC message would be: /Keyboard/MIDI/Channel_1/Note_On, tt: “ii”, 69, 79.

As OSC messages are designed to be sent over a network, you need to define where you want to send your message, and what the message contains.

You must define the following things:

IP Address – The IP address of the device where you send your message. All devices on your network must have a unique IP address. IP address on a local network usually start with 192.168.x.x. In some cases, you can use broadcast addresses.

That is, you broadcast the OSC data to every device on your network and only those that are listening on a particular port will act on it. You must be very careful doing this though. In a poorly planned network, you could easily flood it and performance would suffer greatly.

Port – The port number is like a box number for an IP address. Say you have a block of 50 apartments at 100 Smith St. The apartment numbers would be 1 to 50 at 100 Smith St. That is what ports numbers are to an IP address.

Therefore, you send your OSC stream to an IP address on a particular port number, and the receiver must be listening on the same port number otherwise the stream will not get though.

This could basically be any number, but a lot of ports are reserved for other purposes. Use a 4- or 5-digit number to stay out of the range of most common ports. For example, 8888.

Address Pattern – This usually looks like a URL. It is used to differentiate between different messages you are sending on one port. Example: /your_lighting_desk_name/scene_ number 27 or /your_sound_console_name/channel 5 volume 0.7

So, what can you do with OSC? A superb example is DiGiCo’s implementation on their SD consoles.

You can define your own OSC messages in the console software and use the console itself to send these messages via the console’s Ethernet connection to the device you want to control.

The connection is bi-directional, so the remote device can also update the console’s generic OSC controls if settings are changed on the device itself.

For example, if you have a tracker on the talent onstage, using OSC you can dynamically position their voice in an immersive sound system such as d&b audiotechnik’s Soundscape or L-Acoustic’s L-ISA.

Lots of equipment and software has implemented OSC in all budget ranges. Lighting consoles, sound consoles, media servers, Pro Video Player, Disguise, Qlab, Resolume, Ableton Live, TouchDesigner, MaxMSP, Reaper, ProTools.

The list is endless and keeps growing and for equipment that does not support OSC, third parties often make bridging utilities such as Daniel Büchele’s OSC bridge for Black Magic ATEM switchers (link below).

Want to have a try building an OSC controller? If you are an iOS user, you can install the dirt cheap TouchOSC which lets you create a customisable OSC (and MIDI) controller on your iPad.

However, the exciting new controller is OSC/PILOT. Conceived and used by Deadmau5 (the Canadian electronic music producer, DJ, and musician for our older readers), OSC/PILOT is a bi-directional control surface application originally built as a performance tool for digital artists and musicians.

Running on Windows, ideally with a multi-touch display, you can quickly build some very impressive and powerful user interfaces. In edit mode, widgets are dragged into workspaces and can have parameters adjusted to customise their look and behaviour.

It supports 32 workspaces and even supports NDI which means you can bring video content onto your workspaces.

OSC is a nice protocol that is well designed for pulling together show networks.

Touch OSC – iPad OSC and MIDI Controller
https://hexler.net/products/touchosc

OSC/PILOT – OSC and MIDI Controller on Windows
https://oscpilot.com

ATEM OSC – OSC Software bridge for Black Magic Designs ATEM switcher
https://medium.com/@danielbuechele/atemosc-osc-bridge-for-controling-atem-switchers-34e2182165a2

‘Mission Critical Show Networking‘ – CX Magazine, CX118
https://www.cxnetwork.com.au/mission-critical-show-networking

More by Simon Byrne in CX Magazine:
Networking
www.cxnetwork.com.au/network-switches

Control:
www.cxnetwork.com.au/get-control-centrally
www.cxnetwork.com.au/stream-decks-companion

CX Magazine – February 2021   

LIGHTING  |  AUDIO  |  VIDEO  |  STAGING  |  INTEGRATION

Entertainment technology news and issues for Australia and New Zealand
– in print and free online www.cxnetwork.com.au

© VCS Creative Publishing