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 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.
Most EM readers are familiar with Reaktor but might not know of IanniX. IanniX (le-hub.org) is a freeware version of the UPIC system designed in the 1970s by composer Iannis Xenakis. Like a MIDI controller, it produces no audio on its own but instead sends commands to an audio program or device. What's unique about IanniX is that like UPIC, it allows you to draw shapes and curves for use as musical control signals. It also can be an effective component of a multimedia presentation, with animated visuals accompanying music.
In IanniX you create a score, which is a grid of graphic objects (see Fig. 2). These objects can be trajectories, which can be straight or curved, or cursors, which run along the trajectories like playback heads. You can create any number of trajectories, each with its own cursor that runs independently of the others when the score is played. Trajectories can intersect with curves, so that when a running cursor overlaps with part of a curve, it sends out values that describe the curve. You can also put triggers on trajectories, which send a value when the cursor runs over them.
Both curves and triggers produce OSC messages. IanniX's Control Center lists the transmission information for each curve and trigger. In Fig. 2, there is just one trajectory, cursor, and curve, and messages are sent only to the top level of an address tree. More-elaborate scores can have dozens of trajectories, curves, cursors, and triggers, sending out multiple streams of information.
Can You Hear Me Now?
To make the connection between IanniX and Reaktor, start by checking Reaktor's OSC Setup panel (see Fig. 3). Reaktor recognizes a computer's IP address automatically and displays it here, where you can also assign a Port number, which needs to be in the range of 10,000 to 10,015. You can also monitor incoming OSC messages in this window.
Now jump back to IanniX. Go to the Control Center window and give each score element a distinctive name (in Fig. 2, the curve is named “rover”). Make sure that each element's IP address and UDP port number match the values from Reaktor's OSC Setup panel. You'll also want to go to IanniX's OSC Preferences window and uncheck the option to send Group and Layer identifiers — they're helpful for advanced configurations but can gum up the works for simple communications with Reaktor.
Play the IanniX score once, and you'll see messages appearing in Reaktor's OSC Setup panel. Having thus awakened Reaktor to their presence, you can now assign them to a Reaktor element, such as a fader. Go to the element's Properties panel, where you can create an OSC hook for that element by selecting the name (rover) from the OSC Source pull-down menu. This completes the connection. Play the IanniX score again, and the current value of the Reaktor fader updates and moves in response.
Onward and Upward
The sites for OSC and IanniX have many example files to get you started making OSC connections between various programs. Chances are, something you own is OSC compatible. If the documentation isn't clear on how to establish connections, users groups and Web forums are a good place to find the necessary nuts and bolts. Once a simple connection is made, it's easy to make additional connections, creating complex control networks of different clients and servers.
Mark Ballora teaches music technology at Penn State University.