OSC Tutorial - Part 1 of our OSC tutorial series

This tutorial is part one of a multipart tutorial that will discuss Open Sound Control (OSC) and its usage with M4L. This first part will be dedicated to the discussion of OSC the protocol and a little history.

A quick history: Instruments were originally designed for performance during the early years of electronic instruments. Most of these instruments had little or no capability for even storing presets. You would rotate knobs and press buttons to create a sound and would literally have to take a snapshot (Photo) in order to remember it for next time. As electronic instruments progressed they gradually gained more features. Things were added like Control Voltages (CV) and later on presets. Control Voltage was an early form of an interface used to allow one device to plug-in to another and, "tell" it what to do. The originating device (Usually a analog keyboard) would send out a control voltage to a synthesizer and depending on the voltage, and where the plug was patched into, it could tell the synth what it wanted it do. This was great! We had a way to use one device to tell one or more devices what we wanted it to do. This was probably the earliest form in music of one device controlling another in a standard way. Albeit, different manufacturers used different voltages and not all devices could plug into each other directly. For many years this was all we had. In the 1980's something happened that changed the way we interact with our instruments. First, mass produced, personal computers were introduced to the general public. Second, the MIDI specification was introduced. MIDI is a specification that tells hardware vendors how to intercommunicate in a standard way in order to allow one device to control another. For the first time in history we had a computer which can receive input, process it in some way and output a result and a standard interface (MIDI) to allow that result to, "do something" with a musical device. Pretty soon after the MIDI specs came out some software appeared that allowed users to connect their musical devices that supported MIDI to a computer to record and playback musical notes. As the years progressed the software became more robust, capabilities were added, and computers got more powerful. Skip forward to today, where you have Digital Audio Workstations (DAW)s, that can record audio, process and manipulate audio and midi in realtime and pretty much do anything you can imagine. The one that did not evolve with the technology and is still circa 1980 is MIDI. MIDI is a serial protocol so it is limited to the speed of a serial interface. There are a lot of companies today that use the specification of MIDI for formatting the data to send information from one place to another without using a MIDI interface. This can be faster than traditional MIDI. However, It still seems like you are fitting a square peg into a round whole. There were other factors that came into play, beside the fact that MIDI never evolved from it's 1982 heritage. Musicians wanted to be more creative and interactive with performances and the way they interact with their computer. New forms of devices came out. Devices like touch screens, minimalistic button controllers, interactive body wear, etc... There had to be a better way. A bunch of people at UC Berkeley Center for New Music and Audio Technology (CNMAT) thought so. They developed a specification called Open Sound Control (OSC).
 
What is OSC? Open Sound Control (OSC) is an open, transport-independent, message-based protocol developed for communication among computers, sound synthesizers, and other multimedia devices.
 
What does this mean? This means that we now have a specification that spells out how one device can communicate to another device using a network as a method of transport. Better yet, we have a high speed method of communication that does not rely on serial transport or a limited set of messages.
 
How is it implemented and how do I use it? Good question. I am glad you asked. In order to use OSC you must have a piece of software or a device that allows you to send and receive over a port that you specify. The OSC specification states that OSC is a client/server architecture. This means there are two pieces to the communication. The first piece is the client. The client sends the information to the server. The second piece is obviously the server. The server waits for information to arrive from the server.
 
Lets get a little more technical: In order for OSC to work you must setup the client to send to a specific IP and port and the server to listen on the same port. Here is a quick explanation for those of you who are not familiar with TCP/IP networking. IP addresses are made up of 4 octets (4 numbers seperated by dots) that specify a unique identifier on a network. A port number specifies a uniue identifier for a service. Lets use a street name and house number as a metaphor for IP Address and port. You can think of an IP address as the street name and the port number as the house number. Lets says the is street is, "A street" and the house number is 8000. If a mailman is trying to deliver something to you that you are waiting for at 8000 A street, but he delivers it to 8001 A street will you get it? The answer is no. If he delivers it to 8000 A street (Where you are waiting for it) then you will receive it. The same thing happens with networking if you are a server listening at IP address 192.168.1.1 on port 8000 and the client is sending to 192.168.1.1 on port 8000 then the communication will be successful. The whole idea is just to match the settings on both sides
 
Here is an example of a one way communication:
Device A (Client): OSC client - configured to send to 192.168.1.1 port 8000
Device B (Server): OSC server - listening on port 8000
 
Messaging: How do we format the information to send from an OSC client to OSC server? You need to send the message in OSC format. The format look very close to a directory in DOS or unix. A common tag will look like, "/Osc1/x". The, "/Osc1" specifies a unique identifier and the. "/x" says what you want to modify at that identifier, followed by value(s). You can define your own address and value. They just need to match on the client and on the server. Let's show an example to better illustrate.
 
Same setup as before:
Device A (Client): OSC client - configured to send to 192.168.1.1 port 8000
Device B (Server): OSC server - listening on port 8000 Lets say we had two switches that each sent a 1 when on and a 0 when off
 
When switch 1 is pressed:
Device A will send /switch1/val 1
Device B will receive /Switch1/val 1
 
 
When switch 2 is pressed:
Device A will send /switch2/val 1
Device B will receive /Switch2/val 1 you get the idea.
 
Remember, OSC is a specification for sending and receiving messages. You are not limited to integers. OSC allows for the transmission and reception of 32-bit integers, 32 bit floats, timestamps, Strings, and 32-bit BLOBs. The nice thing about OSC is that it is open ended. This means that whatever you want to send you can receive on the other end. For that matter, there is no reason you have to use OSC just for music. You could theoretically use OSC to send/receive your twitter updates if you really wanted to. All you would have to do is format it in OSC format. For more information on OSC you can go to http://www.opensoundcontrol.org/ In the next tutorial we will go over how to use OSC with MAX. The next tutorial will be a screencast that will better illustrate the intricacies of using OSC in the MAX and M4L environment.