Open Sound Control Primer
This page is intended as a quick explanation of the Open Sound Control protocol from a user's perspective. If you'd like more detail, see the official specification here.
What is Open Sound Control?
Open Sound Control (hereafter abbreviated OSC) is a protocol designed for the transmission of musical control data. It is designed to serve a similar purpose to MIDI, albeit with a far less rigid definition of what constitutes musical control data. It is also a network protocol, meaning that it can be used to send data between computers, tablets, smartphones etc. Essentially, any device connected to your network can send and receive OSC data.
Why use Open Sound Control?
OSC was designed to overcome the significant obstacles imposed by the continued use of the decades-old MIDI standard. Obstacles such as:
- MIDI data is limited to 7-bit words. This means that, for example, MIDI Control Change messages can only ever represent 128 discrete values. This can be particularly problematic when a MIDI controller is mapped to a filter cutoff, for example, where you will hear audible 'stepping' if the filter programmer did not add in some kind of interpolation. (to be fair, the MIDI spec does allow for special 14-bit CC messages, but these are rarely implemented)
- MIDI was designed with the Western musical scale in mind, and particularly, focused on keyboard instruments. It specifies 128 discrete note values, and does not handle issues such as glissandi or alternate scales without complicated workarounds.
- MIDI uses a fixed 31.5kBaud transmission rate. This is painfully slow compared to today's hardware, and can lead to congestion when multiple MIDI devices are all transmitting/receiving data simultaneously.
- MIDI does not handle multiple input devices particularly well. In order for, e.g. multiple input devices to be connected to a single MIDI synthesizer, each input must be set to a unique channel, of which there may only be a maximum of 16. If more inputs are required, additional MIDI interfaces are required.
OSC has none of these limitations.
What do I Need to Know?
IP Addresses and Ports
As a network protocol, OSC relies on IP addresses to identify where OSC messages should be sent. Basically, any device connected to your network has a unique IP address assigned to it. For an OSC client (the device/software which is transmitting OSC data) to send messages to an OSC server (the device/software which is receiving OSC data), it simply needs to know the IP address and port of the OSC server.
Ports are a way of ensuring specific network data gets routed to the correct application for that data (e.g. webpage data is received on port 80). A port is just a 16-bit number. When sending/receiving OSC data, you can essentially pick an arbitrary port number, as long as it is greater than 1023 (numbers 0->1023 are reserved for various system uses).
To summarise; an OSC server needs to be told to listen on a specific port; any OSC client that wants to communicate with that server will need to know the port the server is listening on, and the IP address of the device the server is running on.
OSC Addresses
Any data sent via OSC is sent alongside an OSC address. This is simply a piece of text that specifies what that data refers to. Essentially, a single OSC message looks something like this:
/1/slider1 0.5
/1/slider1 is the OSC address of the message, and 0.5 is the data of that message. For an application like the Pedalboard to then make use of this message, it needs to be told that any messages with the OSC address /1/slider1 should be mapped to a particular plugin parameter or application function.
All OSC devices and software transmit OSC messages like the above. One thing to note is that (to date) there is no agreed-upon standard regarding the naming of OSC addresses; an OSC address can be anything, as long as it starts with a forward-slash. Fortunately, the Pedalboard has a basic OSC learn function which can be used to determine the OSC addresses used by any particular OSC client device.