OSCulator Wiki

The Open Sound Control protocol is at the heart of OSCulator, and therefore the way the user interface is laid is greatly inspired from the way OSC messages are made.

Dave Phillips wrote a very nice introduction to the OSC protocol at the Linux Journal, worth reading. The Wikipedia page is a bit on the technical side, and does not really give useful information for the end user.

The great majority of OSC software and device use the Ethernet or WiFI network to transmit data. That means that OSC messages can be easily sent from one machine to another, or on the same machine across applications.

To make this work, one needs an OSC client, and an OSC server. An OSC client is a device that sends OSC data to an OSC server. An OSC server receives incoming data on a port that it owns. A port is merely represented by a number¹⁾. Most OSC compatible software is both a server and a client, that means it is able both to send data, and receive data. If you are familiar with the MIDI jargon, an OSC server is like a MIDI input, and an OSC client is like a MIDI output.

An OSC message is made of two parts: the address, and the arguments. The address is the name of the OSC message (eg. “/1/fader1”), and the arguments is the list of values supplied with this message (eg. the coordinates of a touch screen would have two arguments, one for X and the other for Y).

For example, the JazzMutant's Lemur Multiball control output two OSC methods each having as much arguments as there are ball in the control, hence with 2 balls:

 /Multi/x  0.20 0.87
 /Multi/y  0.51 0.13

will be displayed in OSCulator as 2 OSC messages, each one having 2 events:

 /Multi/x
    [0]
    [1]
 /Multi/y
    [0]
    [1]

Each of these events can be mapped to different events: MIDI control change, Keyboard stroke, Kyma Event (aka Kyma CC), etc.