OSC Communication:
Guides | External Control > OSC

OSC Communication

OSC network communication

OSC communication between programs is often done to send messages from one application to another, possibly with the applications running on different computers. In SuperCollider this communication is done by creating a NetAddr of the target application and creating an OSCFunc to listen to another application. The underlying protocol of OSC is either UDP or TCP.

Sending OSC to another application

To establish communication to another application, you need to know on which port that application is listening. For example if an application is listening on port 7771, we can create a NetAddr and send it a message:

Receiving OSC from another application

To listen to another application, that application needs to send a message to the port SuperCollider is listening on. Normally the default port is 57120, but it could be something different if that port was already bound when SC started. The current default port can be retrieved with

Or you can retrieve both the IP and the port with:

You can open additional ports using Main: -openUDPPort. This will return a Boolean indicating whether SC succeeded in opening the new port. Or you can just pass a custom port as the recvPort argument to OSCFunc and it will open it automatically if not already open.

To listen to incoming messages, an OSCFunc needs to be created in SuperCollider. If the sending application has a fixed port it sends message from, you can set the OSCFunc to listen only to messages coming from that IP and port:

NOTE: The port 7771 above is the port the other application is sending from, not the port SC is receiving on. See the recvPort argument in OSCFunc: *new if you want to receive on another port than NetAddr.langPort.

Receiving from an application that is sending from a variable port

Some applications (notably Pd and Max) do not send messages from a fixed port, but instead use a different port each time they send out a message, or each time a patch starts up it picks a random port. In that case the OSCFunc needs to be set up, so that it listens to messages coming from anywhere. You do this by passing nil as the srcID argument.

Testing incoming traffic

OSCFunc has a convenience method, OSCFunc: *trace which posts all incoming OSC messages:

Custom OSC message processing

All incoming OSC messages call the message recvOSCmessage in Main. If needed, one can add a custom Function or other object to Main's recvOSCFunc variable. Although one can do this directly using the corresponding setter, it is better to use the Main: -addOSCRecvFunc and Main: -removeOSCRecvFunc to avoid overwriting any other functions that may have been added by class code.

OSC type tags and sclang

Inbound OSC messages must have type tags, or an error will be thrown.

The following conversions are supported outbound:

If NetAddr.useDoubles is set to true, then in outbound messages, sclang will use the "d" (double) type tag instead of "f". OSC doubles are 64-bit. It is up to you to ensure that the receiver understands "d".

The following type tags are supported inbound:

"r" (RGBA color), "S" (symbol), and "[" and "]" (array start and end) are not supported.

If an unrecognized tag is encountered, sclang will make that unrecognized tag into a Char object and add that to the OSC message. It will then skip ahead in the OSC message as if it were reading a string -- it looks for the next null byte and then skips 0-3 bytes for 4-byte alignment.