2003: OpenSound Control: State of the Art 2003

Abstract

OpenSound Control (“OSC”) is a protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology. OSC has achieved wide use in the field of computer-based new interfaces for musical expression for wide-area and local-area networked distributed music systems, inter-process communication, and even within a single application.

Appendices

Open Sound Control: Some Context and Reflections on Thirteen Years’ Advances

Matthew Wright and Adrian Freed

OSC is a widely used encoding in NIME projects and this paper (the 4th on OSC) provides practitioners with a solid introduction on what OSC is and how it they might use it. Although today we distinguish the terms “encoding” and “protocol” and tend to be more specific when talking about “client” and “server,” OSC essentially has not changed since this paper. Receiving a message, modeled here as “directing” a “kind of message” and its “arguments” to “entities” within the receiver, can now be thought of as parallel assignment or writing to a key/value store such as a “record,” “dictionary,” “associative array,” or “ property list,” but the underlying interoperable machinery remains substantially identical. Today’s wealth of OSC APIs and libraries for most active programming languages (including the 38 “programming language libraries” on opensoundcontrol.org) allows most users to ignore the details of the encoding.

This was the first OSC paper to describe type tags, one of the only new features since the original 1997 ICMC paper. Credit belongs to James McCartney, who needed to support situations where the sender did not know in advance what types the receiver expected for each message, or where type polymorphism (same message name, different argument types) was desired. Just as CNMAT had unilaterally defined and implemented OSC, McCartney unilaterally defined and implemented OSC type tags (originally optional, hence the funny comma character), which CNMAT later adopted and are now universal.

Today OSC-encoded packets are embedded in many kinds of data streams and transported among devices with different wired and wireless protocols, including SLIP via USB serial or “TTL” serial; TCP via web-, UNIX, or Windows sockets; and most often UDP packets via TCP/IP based LANs and WANs.

OSC use preceded that of the popular XML and JSON encodings, which both have simpler representations for hierarchical data than OSC’s anonymous recursive subbundles (which are rarely implemented, tested, or used). OSC now supports bundles as message arguments.

This paper continued our tradition of talking about a query system that didn’t really exist; today there are several incompatible query systems none widely implemented. The paper’s optimism that “obviously” all implementations would eventually support every feature of OSC has given way to accepting the fact that there will always be incomplete implementations.

OSC has traveled into many different development communities who use it in innovative ways not envisaged by its inventors. Although in 2003 we believed we were aware of almost all OSC use, the full history and extent of its cultural uptake is still to be carefully chronicled. Although the existence of the OSC Kit may have helped adoption of OSC, to our knowledge nobody actually fully used it as designed. Some implementations used portions of it (e.g., pattern matching) but most reimplemented OSC until the existence of other libraries such as oscpack and liblo. On the other hand, sendOSC and dumpOSC are still indispensable, confirming whether valid messages are sent and their contents (or the specific problem if invalid), and helping troubleshoot networks, firewalls, address space mismatches, faulty arguments, etc.

OSC has also traveled to many creative communities outside of computer music. Within the domains of virtual and augmented reality (Unity, Unreal Engine), staged dramatic works with complex media-design (Processing, OpenFrameworks, D3, Millumin, Madmapper, TouchDesigner), modeling and fabrication (Rhino Grasshopper with gHowl), physical computing and Internet of Things applications (software: ROS, oscuino, Maxuino; hardware: Particle SparkCore, ESP8266) many practitioners are adapting OSC for their needs in communicating among several processes, platforms, or locations.

We offer this broad taxonomy of current use patterns:

• 1. Client/server: e.g., communications between computers optimized for user interaction (e.g. Apple Macintosh) and machines optimized for computing performance (e.g. SGI O2), Meyer/LCS spatial audio and show control

• 2. Inter-Process communication, e.g., between Max and synthesis “servers” on the same machine, Supercollider, OpenSound World...

• 3. Inter-Media synchronization and communication, e.g. between Unity as a real-time visual virtual reality and Max as a synthesizer for responsive environmental sound

• 4. Synchronization and automation, netjamming

• 5. Transcoding and wrapping (as described in Sect. 5.4), e.g., TUIO for multitouch, DMX lighting control, many wrappers in CNMAT’s MMJ Depot, and o.io.

• 6. Native encoding for input and output devices (MIDI alternative), e.g., Monome, OSC for Arduino, many phone and tablet apps. (We note that all of the commercial hardware projects listed in Sect. 2.6 are now gone, but many others have taken their place)

• 7. Extension language (o dot, gdif, spatdif)

• 8. dynamic programming hooks (OSW)

Regarding education, though in 2003 institutions teaching OSC were noteworthy, today one would expect OSC in any computer music or interactive digital arts program and especially in any hands-on NIME course.

Expert Commentary: OpenSound Control: State of the Art 2003

Roger B. Dannenberg

OpenSound Control (OSC) has become a standard building block for not only music systems but any number of interactive art installations, virtual reality systems, and other systems needing distributed control and communication. OSC follows a long history of protocols including MIDI for music, ZIPI, intended to extend and replace MIDI, CORBA and DCE, middleware for distributed computing. A series of protocols for the Web followed earlier developments, resulting in HTTP, SOAP, REST, and certainly more will come. With all these distributed systems protocols, it is surprising that OSC has gained so much traction. Why OSC?

John Huntington (Huntington 2008) describes some “common attributes of successful standards,” including “Successful standards are pulled into existence by the market; they are not pushed. They fill a clear commercial demand in the market, especially one driven by users.” One could argue that OSC greatly simplified existing standards and better met the requirements of interactive music programs. However, even ZIPI was said to have an “unusual addressing scheme which required substantial increase in complexity,” (Wikipedia 2014) and OSC’s addressing scheme is even more complex. When announced, many complained that the pattern-matching features in OSC and the URL-like addresses would be too slow and difficult to implement. On the other hand, OSC arguably was and still is too simple. OSC was modified to include datatype information and is still considered to have problems with queries, discovery, timestamps, and the use of different transports. Whatever the reasons, OSC has been wildly successful, especially as an open technology with academic origins.

One explanation for OSC’s popularity could be that it lowers the barriers to interfacing with Max/MSP and Pd (Puckette 2002), two very popular visual programming systems used by musicians and artists. Without OSC, one can extend Max/MSP or Pd by writing “external” objects in C, but this requires a rather detailed knowledge of internal program structures and interfaces. Once OSC “objects” were created for Max/MSP and Pd, one could extend these programs through OSC. For example, one can now build a sensor that sends data through very simple network packets. Using OSC with Max/MSP and Pd solves both the connection problem (just use Ethernet or WIFI) and the interface problem (forming and sending simple network packets is simpler than developing “externals”). The inter-operability, modularity, and distributed processing support resulting from a network-based protocol are all added attractions, but could it be that the desire to connect to Max and Pd drove widespread adoption of OSC?

What is next? When OSC was announced, the fastest personal computers were comparable to today’s smartphones. Now that even low-cost embedded processors used for sensors are quite capable of running sophisticated software, one can imagine much more powerful protocols being deployed as “standards” in the worlds of interactive art and music. But going back to systems like CORBA seems unlikely to catch hold. A lesson we can take from OSC and the Web is that, while highly optimized binary protocols may be attractive for performance, the flexibility of symbolic addresses and late or dynamic binding is more important to most users. I can imagine the next generation of interprocess control being built upon bi-directional network connections where every node runs an active server to offer named services (as opposed to IP addresses and port numbers most often used with OSC), peer-to-peer connections, automatic routing, clock synchronization (Brandt and Dannenberg 1999), web interfaces for performance monitoring and testing, and many other services. Clients might construct URL-like requests that specify a destination by name (“audio-mixer”) to be routed automatically to the node providing that resource. Of course, this would represent a big step up in complexity from OSC, but it might make things simpler for end users.

Whatever happens in the future, OSC has established itself as a versatile standard for inter-process communication, enabling countless systems to be constructed in a modular and flexible way. This paper, “OpenSound Control: State of the Art 2003,” gives an excellent overview of OSC, the designer’s intentions, and how applications use OSC. More than 10 years later, the article is still an excellent way to become acquainted with OpenSound Control.