Open Sound Control

I. Introduction to OSC

Open Sound Control (OSC) is a protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology. OSC’s advantages include interoperability, accuracy, flexibility, and enhanced organization and documentation.

 

1.1 Purpose and History

OSC was invented in 1997 by Adrian Freed and Matt Wright at The Center for New Music and Audio Technologies (CNMAT). It was developed to meet the needs of musicians that wanted more control over sound parameters than the current standard, Musical Instrument Digital Interface (MIDI), could provide, and its initial purpose was to enable computers, sound synthesizers, and other multimedia devices to communicate with each other.

 

1.2 Transmission Principles

OSC supports a client/server architecture, in which a client sends OSC data to a server. Usually, OSC requires an IP address and host number for connection, especially to open a remote control from one device to another over a local network. Each service can only listen or send data through its assigned port. For example, if you are using one application on your smartphone to control another on your laptop, you need to set up the corresponding IP address and the port number on the smartphone to decide which destination the data will go to, as well as define the same port number on the laptop side. When transmitted over serial, such as USB, OSC requires extra data as an indicator. SLIP(Serial Line Internet Protocol), for example, can be used as a framing protocol to packetize data over serial. The datagram and serial stream transmission will be explained in more detail in the second chapter of this article.

The unit of transmission of OSC is an OSC Stream. This can be carried in message-based network protocol such as User Datagram Protocol (UDP), or stream-based protocol such as Transmission Control Protocol (TCP). The following diagram illustrates the format structure of an OSC stream.

Diagram 1- Architectural Overview of an OSC Stream

 

 

1.3 Format Structure

OSC streams are sequences of frames defined with respect to a point in time called a time tag, and these frames are called bundles (as OSC Bundle in Diagram 1). A bundle is a sequence of messages and/or an OSC-string identifier “#bundle”, and an OSC time tag, followed by zero or more elements. The OSC message is the basic unit of OSC data consisting of an address pattern, a type tag string, and arguments. The following sections will describe the OSC time tag and the OSC message in detail.

1.3.1 OSC Time Tag

A time tag specifies the desired absolute time at which the messages in the bundle should take effect. For example, it can be used to schedule when a note should be played. If a received OSC stream contains only a single bundle, the OSC server should unpack it and invoke the corresponding OSC method. Otherwise, the time tag determines when the OSC methods should be invoked. If the time tag represents a time in the future, the server should store the bundle until the specified time arrives. If the time tag is equal to or before the current time, the server should unpack it and invoke the method immediately.

1.3.2 OSC Address Pattern

An OSC address pattern is a character string beginning with the forward slash (/), as it is the full path from the root of the address space tree to a particular node. For example, the address /voices/3/freq refers to a node named ‘freq’ that is a child of a node named ‘3’ that is a child of a top-level node named ‘voices’. Since the address is with a slash-delimited format like a Uniform Resource Locator (URL) or file system pathname, it is human-readable and easy to organize.

1.3.3 OSC Type Tag String and Arguments 

A type tag string is a string beginning with a comma (,), followed by a sequence of characters corresponding exactly to the sequence of OSC Arguments in the given message. Each character after the comma is called an OSC Type Tag and represents the type of the corresponding OSC Argument. The different data types OSC Arguments support are int32, float32, ASCII strings, and blobs. Other types of data some OSC implementations support are 64-bit numbers, RGBA color, ‘True’, and ‘False’.

II. OSC as a Transport-independent Protocol 

OSC is a network protocol that is ‘transport-independent’ and carries messages in binary format. Transport-independence means it can be free from compatibility problems and work over all the various transport options. A common transport protocol used with the OSC format is UDP/IP, but OSC can be encapsulated in any digital communication protocol. 

The Open Systems Interconnect (OSI) model defines a communication model where applications communicate through a layered stack, where the transmitted message passes from the highest layer of the stack to its lowest layer on the transmitting end, and from the lowest layer to the highest layer on the receiver. The reason why OSC is transport-independent is that it is classified as a Layer 6 or Presentation Layer entity in the context of the OSI Model. This layer formats and encrypts data to be sent across a network, providing independence from differences in data representation, for example, different features such as security, compression, and encryption built in many of transport protocols. OSC does not encrypt data, but it is responsible for the delivery and formatting of information to the application layer for further processing.

 

Diagram 2- OSC in the OSI Model

The specific features of each transport can affect the quality and availability of stream data in the application layer.

 

2.1 Datagram Transports: UDP

A datagram transport such as UDP(User Datagram Protocol) is a non-assured transport. Each packet is either delivered in its entirety or not delivered at all. Packets may be out of order, in which case OSC time tags can be used to recover the correct order. In the case of UDP, if the packet exceeds the maximum transmission unit (MTU) the packet may be fragmented over multiple pieces. The fragmentation can introduce extra delay as the UDP/IP stack must then reassemble the pieces before delivering the packet to an application. 

Here’s an example that showcases how to map OSC messages “/s_new”“,s”“,i”“default” 100 to plain Javascript objects, receive and send the bundle over Node.js’s UDP sockets. (osc.js library).

Diagram 3 – Receiving and Sending OSC Message over Node.js’s UDP Sockets

 

2.2 Serial Stream Transports: TCP

Serial transports such as TCP (Transmission Control Protocol)  provide a continuous data stream between endpoints. The OSC content format does not define a means for representing the beginning and end of a packet. In particular, the OSC bundle can contain any number of encapsulated messages and there is no way for a parser to determine the total number until the end of the packet is reached. 

Therefore the major need for sending OSC on serial transport is that the packets must be encoded with some extra data to indicate where the packet boundaries are, called a framing protocol, for example, the SLIP framing protocol. SLIP modifies a standard TCP/IP datagram by:

• appending a special “END” byte to it, which distinguishes datagram boundaries in the byte stream,
• if the END byte occurs in the data to be sent, the two-byte sequence ESC, ESC_END is sent instead,
• if the ESC byte occurs in the data, the two-byte sequence ESC, ESC_ESC is sent.
• variants of the protocol may begin, as well as the end, packets with END.

Specifically for OSC, we use the “double-ENDed” variant of SLIP which places the SLIP_END character at both the start and the end of a frame. Here’s an example of sending a package over serial in C:

Diagram 4 – Sending OSC Message over Serial

III. Comparison between MIDI and OSC

The MIDI protocol, first released in 1983, was developed by a group of American and Japanese synthesizer manufacturers, who wanted to create a standard protocol to transfer musical data between instruments. This standardization was accomplished by having predefined messages, a standard transfer protocol, and a standard file format. Any MIDI capable device can connect to any other MIDI device and communicate. There are thousands of software and hardware products that support MIDI, compared to the dozens that support OSC. In contrast, OSC is an open-source network protocol with a dynamic, open-ended, URL style-naming scheme, which allows the user to determine the address space. 

 

3.1 Addressing Feature

 

	OSC	MIDI
Example of  Messages	channel/4/freq 1454.1 play-note/17 0.5	0x90 0x3C 0x7F (Note On for C4, max velocity) 0x90 0x40 0x7F (Note On for E4, max velocity)
Message  Types	Human-readable, User-defined	Byte-encoded, Predetermined

Table 1 –  Comparison of OSC and MIDI

As mentioned in section II, the specifics of OSC, which are a large part of its uniqueness and strengths, are the naming scheme, numeric and symbolic argument messages, pattern matching language, high-resolution time tags, bundles of messages, and a query system to dynamically find the capabilities of an OSC server and get documentation. Its biggest strength, which allows each user to design an address space instead of selecting a predetermined set of parameter names, is also its weakness since it is easily adaptable to situations never envisioned by the designers. Because each user can name their own address spaces, these fields can easily be identified by name, it could be confusing sometimes for people who don’t know the actual data packaged inside to see the same name address used in different applications in different ways. The lack of standardization of OSC is one of the reasons it has never replaced MIDI.

The MIDI protocol uses a compact binary message format with a limited number of fields due to the low bandwidth of the connection and the need for real-time accuracy. Each MIDI connection carries a stream of MIDI messages made up of 8-bit bytes. Most messages consist of a status byte, channel number in the low 4 bits, for a total of 16 channels, and an opcode in the high 4 bits, followed by one or two data bytes.

Although the string-based OSC namespace is more efficient for a human to evaluate, a numerical value is much more efficient for the computer because computers are arithmetic devices. For example, in a performance where a mapped point is changed one hundred times a second, the human would not be expected to read that value for every message sent; however, the computer is. Hence, the message is optimized for the entity that requires it least during the performance. 

 

3.2 Speed Comparison

There is a belief in the NIME community that OSC is a fast communications protocol; for example, “The choice for OSC … was for its high speed, powerful protocol, and independency”. Statements such as these are normally based on a comparison between the data transmission rate between OSC and MIDI in their typical applications. It is, however, misleading to compare the speed of OSC to MIDI based on the data transmission rate because OSC does not have a data transmission rate.

OSC does not define anything below the presentation layer in the OSI model, and its messages are transported across the internet and within local subnets using UDP/IP and Ethernet, which has a standard data rate of at least 10 Megabits per second (10 Mbps). MIDI, however, can be defined using the OSI model from its application layer right down to the physical layer. That’s why the speed comparison between OSC and MIDI is always made at the 10 Megabits per second in OSC and 31.25 Kilobits per second (31.25 Kbps) in MIDI, so the inventor of OSC Wright and Freed state that MIDI is “roughly 300 times slower” than OSC.

However, when carried on Ethernet, MIDI bits move at the same data rate as OSC bits carried on Ethernet because the data rate is a factor of the transport, not the protocol. In the meanwhile, in terms of throughput, MIDI can actually have better throughput than OSC because it takes fewer bytes to make common MIDI messages than it does to make comparable OSC messages.

 

3.3 Applications

OSC is typically transmitted over ethernet. Typical applications of OSC are originally in the same area as MIDI applications. OSC’s typical application areas are sensor/gesture-based electronic musical instruments, mapping nonmusical data to sound, multiple users shared musical control, the web interface to sound synthesis, networked Local Area Network (LAN) musical performance, Wide Area Network (WAN) performance, and virtual reality.

MIDI often defines a hardware interface, for example, the MIDI cable and the MIDI pad. One common MIDI application is to play a MIDI keyboard or other controller and use it to trigger a digital sound module, which contains synthesized musical sounds, to generate sounds, which the audience hears produced by a keyboard amplifier.

 

3.4 Fun Facts:  Inaccurate Comparisons between OSC and MIDI

The MIDI Association pointed out that some articles about new OSC supported products appearing in publications have contained potentially misleading statements and inaccurate comparisons between OSC and MIDI. The following is a chart comparing OSC to MIDI, provided in the document “Open Sound Control – A Flexible Protocol for sensor networking” published in the OSC official website.

Table 2 –  Comparing OSC to MIDI, the chart provided by Freed, Schmeder, Zbyszynski

While OSC can do many things that MIDI is not designed to do, The MIDI Association states that some of the claimed advantages listed in this chart are only true under specific conditions, such as when using the MIDI DIN transport or using predefined messages. The MIDI Association corrects the following statements including: 

• MIDI is a hardware transport-independent protocol, MIDI is as Fast as OSC, MIDI supports multiple data formats, 
• MIDI offers pre-defined and product-specific message structures, MIDI offers greater interoperability than OSC, 
• MIDI has applications in a wide variety of areas besides music, 
• “Time-tagging” of MIDI events is possible on all the same transports as OSC, and 
• MIDI sends clocks at quarter-frame SMPTE accuracy.

 

IV. Conclusion

In short, OSC is a network protocol that is transport-independent and carries messages as bundles. This protocol provides real-time control of sound and other media processing and has been used in web interactivity tools, software synthesizers, a large variety of programming languages, and hardware devices for sensor measurement. 

 

1. References

1. Wright, M., Freed, A., Momeni A. Open Sound Control: State of the Art 2003. Proceedings of the 3rd Conference on New Instruments for Musical Expression (NIME 03), Montreal, Canada, 2003.
2. Open Sound Control website: opensoundcontrol.org
3. Wright, M. Open Sound Control: an enabling technology for musical networking in Organised Sound. 10(3), Cambridge University Press, 2005.
4. MIDI Manufacturers Association Incorporated: https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
5. Brandi Rose, Thomas Haighton, Danyi Liu. Open Sound Control, 2015
6. Fraietta, A., The Smart Controller: an integrated electronic instrument for real-time performance using programmable logic control, School of Contemporary Arts. 2006, University of Western Sydney.
7. OSI Model: https://www.webopedia.com/quick_ref/OSI_Layers.asp
8. Adrian Freed, Andy Schmeder. Features and Future of Open Sound Control version 1.1 for NIME.
9. Open Sound Control – A Flexible Protocol for sensor networking: http://opensoundcontrol.org/files/OSC-Demo.pdf
10. White Paper: Comparison of MIDI and OSC: https://www.midi.org/midi/articles/white-paper-comparison-of-midi-and-osc
11. Andrew Schmeder and Adrian Freed and David Wessel. Best Practices for Open Sound Control.
12. Open Sound Control. https://en.flossmanuals.net/pure-data/_full/#osc
13. OSC over the USB serial transport. http://cnmat.berkeley.edu/content/osc-over-usb-serial-transport