{"id":399,"date":"2019-12-19T16:43:50","date_gmt":"2019-12-19T21:43:50","guid":{"rendered":"https:\/\/itp.nyu.edu\/networks\/?page_id=399"},"modified":"2020-02-23T14:10:00","modified_gmt":"2020-02-23T19:10:00","slug":"open-sound-control","status":"publish","type":"page","link":"https:\/\/itp.nyu.edu\/networks\/explanations\/open-sound-control\/","title":{"rendered":"Open Sound Control"},"content":{"rendered":"

<\/span>I. Introduction to OSC<\/b><\/span><\/h4>\n

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\u2019s advantages include interoperability, accuracy, flexibility, and enhanced organization and documentation.<\/span><\/p>\n

 <\/p>\n

1.1 Purpose and History<\/b><\/p>\n

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<\/span>.<\/span><\/p>\n

 <\/p>\n

1.2 Transmission Principles<\/b><\/p>\n

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<\/span>. 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<\/span>. The datagram and serial stream transmission will be explained in more detail in the second chapter of this article.<\/span><\/p>\n

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.<\/span><\/p>\n

\"\"<\/p>\n

Diagram 1- Architectural Overview of an OSC Stream<\/span><\/p>\n

 <\/p>\n

 <\/p>\n

1.3 Format Structure<\/b><\/p>\n

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 \u201c#bundle\u201d, 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.<\/span><\/p>\n

1.3.1 OSC Time Tag<\/b><\/p>\n

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<\/span>. 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.<\/span><\/p>\n

1.3.2 OSC Address Pattern<\/b><\/p>\n

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 \u2018freq\u2019 that is a child of a node named \u20183\u2019 that is a child of a top-level node named \u2018voices\u2019<\/span>. Since the address is with a slash-delimited format like a Uniform Resource Locator (<\/span>URL<\/span><\/a>) or file system pathname, it is human-readable and easy to organize.<\/span><\/p>\n

1.3.3 OSC Type Tag String and Arguments<\/b>\u00a0<\/span><\/p>\n

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<\/span>. 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, \u2018True\u2019, and \u2018False\u2019<\/span>.<\/span><\/p>\n

<\/h4>\n

<\/span>II. OSC as a Transport-independent Protocol\u00a0<\/b><\/span><\/h4>\n

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

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. <\/span>The reason why OSC is transport-independent is that it <\/span>is classified as a Layer 6 or Presentation Layer entity<\/span> in the context of the OSI Model<\/span>. This layer formats and encrypts data to be sent across a network, providing independence from differences in data representation, for example, different <\/span>features such as security, compression, and encryption built in many of transport protocols.<\/span> OSC does not encrypt data, but it <\/span>is responsible for the delivery and formatting of information to the application layer for further processing.<\/span><\/p>\n

 <\/p>\n

\"\"Diagram 2- OSC in the OSI Model<\/span><\/p>\n

The specific features of each transport can affect the quality and availability of stream data in the application layer.<\/span><\/p>\n

 <\/p>\n

2.1 Datagram Transports: UDP<\/b><\/p>\n

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.\u00a0<\/span><\/p>\n

Here\u2019s an example that showcases how to map OSC messages <\/span>\u201c\/s_new\u201d\u201c,s\u201d\u201c,i\u201d\u201cdefault\u201d 100<\/span> to plain Javascript objects, receive and send the bundle over Node.js’s UDP sockets. (<\/span>osc.js library<\/span><\/a>)<\/span>.<\/span><\/p>\n

\"\"<\/p>\n

Diagram 3 – Receiving and Sending OSC Message over Node.js\u2019s UDP Sockets<\/span><\/p>\n

 <\/p>\n

2.2 Serial Stream Transports: TCP<\/b><\/p>\n

Serial transports such as TCP (Transmission Control Protocol)\u00a0 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.\u00a0<\/span><\/p>\n

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<\/span>. SLIP modifies a standard <\/span>TCP\/IP<\/span><\/a> datagram by:<\/span><\/p>\n