Research Article O2: A Network Protocol for Music Systems Roger B. Dannenberg School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213, USA Correspondence should be addressed to Roger B. Dannenberg; rbd@cs.cmu.edu Received 2 January 2019; Revised 18 March 2019; Accepted 4 April 2019; Published 6 May 2019 Guest Editor: Federico Fontana Copyright © 2019 Roger B. Dannenberg. Tis is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. O2 is a communication protocol for music systems that extends and interoperates with the popular Open Sound Control (OSC) protocol. Many computer musicians routinely deal with problems of interconnection, unreliable message delivery, and clock synchronization. O2 solves these problems, ofering named services, automatic network address discovery, clock synchronization, and a reliable message delivery option, as well as interoperability with existing OSC libraries and applications. Aside from these new features, O2 owes much of its design to OSC, making it easy to migrate existing OSC applications to O2 or for developers familiar with OSC to begin using O2. O2 addresses the problems of interprocess communication within distributed music applications. 1. Introduction Music sofware and other artistic applications of computers are ofen organized as a collection of communicating pro- cesses. Simple protocols such as MIDI [1] and Open Sound Control (OSC) [2] have been very efective for this, allowing users to piece together systems in a modular fashion. Shared communication protocols allow implementers to use a variety of languages, apply of-the-shelf applications and devices, and interface with low-cost sensors and actuators. In addition, mobile applications intrinsically run on multiple distributed host computers and require a communication protocol for any kind of coordination. Figure 1 illustrates several common organizations for net- worked music systems. Figure 1(a) shows the “input/mapper/ output” structure, where sensors and input devices stream values to a control system that maps sensor values to control parameters, which are passed on to a music synthesizer or audio signal processor [3]. Examples of this approach include SensorChimes [4] and play-along mappings of Fiebrink et al. [5]. Te libmapper system is a communication protocol designed to support this approach [6]. Figure 1(b) illustrates a “conductor/ensemble” structure commonly used in laptop orchestra and mobile device music systems. Multiple performers can join and leave the ensemble by connecting to a central conductor or coordinator that directs the performers. Examples are described by Essl [7], Trueman et al. [8], and Dannenberg et al. [9]. Tis same confguration is used in wide-area networked music perfor- mances on a global scale such as quintet.net [10] and the Global Network Orchestra [11]. Figure 1(c) illustrates a peer-to-peer organization that is used in networked performances characterized by autonomy and emergent behavior as opposed to the top-down control seen in the conductor/ensemble model. Gresham-Lancaster ofers an interesting early history and discussion of this approach [12]. More examples of all three structures are described by Wright [13]. In all of these patterns, we see networking has advanced from point-to-point communication to more fexible and comprehensive communication substrates ofen used as much for sofware modularity and resilience as for communi- cation. We introduce the protocol, O2, that provides for com- munication and coordination among music processes and ofers some important new features over previous protocols such as OSC. A common problem in any distributed system is how to initialize connections. For example, typical OSC servers do not have fxed IP addresses and cannot be found via DNS servers as is common with Web servers. Instead, OSC users usually enter IP addresses and port numbers manually. Te numbers cannot be “compiled in” to code because IP addresses are dynamically assigned and could change between development, testing, and performance. O2 Hindawi Wireless Communications and Mobile Computing Volume 2019, Article ID 8424381, 12 pages https://doi.org/10.1155/2019/8424381