Square One: Open Sound Control

Nov 1, 2008 12:00 PM, By Mark Ballora

           
 

USING OSC TO SHARE DATA BETWEEN APPLICATIONS

In “Square One: Into the Ether” (see the September 2008 issue, available at emusician.com), Brian Smithers discussed alternative protocols for MIDI and audio, one of which was Open Sound Control. In this article, I'll show you how to get two programs to communicate via OSC. Thierry Coduys and Guillaume Ferry's IanniX, a graphical music-control program, will control audio that's generated in Native Instruments Reaktor. I'll cover enough essential parameters to get you started connecting any two OSC-compatible applications.

OSC was invented in 1997 at the UC Berkeley Center for New Music and Audio Technologies (CNMAT; opensoundcontrol.org), and the protocol controls networked sound modules and multimedia devices. Typically, OSC is transmitted between devices via Ethernet cables, which are more commonly used to connect computers to the Internet — although in a simple configuration, one piece of software can control another on the same computer. In a complex setup, a device can control any other device connected to the Internet to create a performance that transcends geography.

Until recently, OSC dwelt primarily in experimental research environments. Lately, however, it has become an important component of many commercial hardware devices, such as JazzMutant's Lemur (jazzmutant.com) and Angelo Fraietta's Smart Controller (www.smartcontroller.com.au), and software, such as Reaktor (native-instruments.com) and Cycling '74 Max/MSP (cycling74.com).

Think of OSC as an improved version of MIDI. Though MIDI remains essential, it suffers from an inherently limited vocabulary and a shaky sense of time. OSC is more open ended in its vocabulary and is far more precise timewise.

MIDI, Supersized

MIDI is constrained by its 8-byte message format, which limits the range of values and types of messages that can be sent. It requires an arbitrary numbering of channels, patches, controllers, and the like. OSC's message structure allows more-detailed messages that consist of text and numbers. This means that any software or hardware synthesizer supporting OSC could have any combination of parameters, and any other supporting device could control those parameters by simply declaring their name and a value to be applied.

Moreover, MIDI is slow, transmitting at 31.25 kilobaud. Things can bog down with dense streams such as multiple continuous controllers. In contrast, OSC transmits some 300 times faster over Ethernet, typically in the range of 10-plus Mbps, using the Internet Network Time Protocol, which synchronizes machines at the subnanosecond level. In addition, rather than sending messages serially (one at a time) the way MIDI does, OSC allows packets, or groups, of messages to execute at specifically defined times. It's like a fireworks show: shoot out a packet of messages, and all the devices simultaneously flare up into action.

FIG. 1: The oscillators in this graphic are configured in a hierarchical name space, or treelike structure, which allows OSC messages to address different levels of activity in its messaging format.

For communication between devices over the Internet, OSC uses an addressing scheme called an address tree or a hierarchical name space. This protocol allows the devices to use addresses that resemble Internet addresses. Fig. 1 represents a simple example that shows a set of oscillators arbitrarily named “bass,” “tenor,” “alto,” and “soprano.” Each oscillator has controllable parameters for frequency, amplitude, and pan position. The address of the tree-based OSC message that's used to set the tenor oscillator's frequency to 220 looks like this: /oscillators/tenor/freq 220.

Nuts and Bolts

The first step in understanding how to set up an OSC connection is to learn a little terminology. In networkese, devices called clients send messages to receiving devices called servers or hosts. Think of it this way: when you go to a restaurant, you're the client of that establishment — you make requests, and a server or host produces something (a meal) in response.

For a client to control a server, it first has to know the server's Internet Protocol (IP) address, which identifies a machine on the Internet. IP addresses take the form of four numbers separated by periods — sometimes called a dotted-quad formation — which looks something like “127.0.0.1.” The client application then has to packetize the OSC messages and send them over a network port, typically a User Datagram Protocol (UDP) port, which is compatible with the time-sensitive, packetized nature of OSC messages. When the client and server are on the same machine, some applications prefer using the IP address localhost (meaning “this machine here”), as opposed to a dotted-quad address.

For a simple OSC startup configuration, it's best to begin with two applications on the same machine and then send control signals from one to the other. For this example, I'll describe how to use IanniX as a client to control sliders in Reaktor, the server.