Proceedings of the International Conference 2011, University of Huddersfield, UK, 31 July - 5 August 2011

RECONSIDERING LAPTOP AS A COMPUTATIONAL GRID FOR MUSIC PERFORMANCE

Stephen David Beck, Chris Branton Center for Computation & Technology Louisiana State University Baton Rouge, Louisiana, USA [email protected], [email protected]

ABSTRACT time, distribute control messages, and manage other per- formance information. [11] Laptop orchestras have become a popular ensemble form Each LO composition consists of a unique combina- for the exploration of interactive computer music as a group tion of software, user interfaces, and physical devices. endeavor. Although its roots date back to the mid-1980s, it Configuration can range from the very simple (a single has only been in the past five years or so that these groups piece of code on each machine), to the very complex (Wii- have been established at universities, schools of music motes, iPads, custom UI and laptops, all driven by a net- and as stand-alone entities. As the number of ensembles worked time-sync). Laptops may all behave the same, or and the number of pieces written for these groups grows, have specialized individual roles. [3] we need better tools to manage the ’s technical side. In reconsidering the laptop orchestra as a compu- tational grid for music, we are able to adopt a range of well-established tools and techniques used for managing scientific computational grids and apply them to this new environment. We will discuss the basis for our position, describe in general some important developments in our research, and highlight some additional steps we are tak- ing to further support the cyberinfrastructure of laptop or- chestras.

1. INTRODUCTION Figure 1. Our ensemble rehearses a work for laptops, Laptop Orchestras [10] (LOs) have recently become a very Wii-motes and an iPad. popular activity among academic institutions interested in identifying innovative teaching methods for electroa- Distribution, management and control of the neces- coustic and computer music education. This interest has sary software across a heterogeneous collection of net- spawned a new generation of ensemble acronyms remi- worked devices is a tremendous challenge for LOs. Each niscent to this author of efforts to name composition has a unique collection of core software, mid- studios with a sense of humor and irony. Ensemble names dleware and user-interface software that must be initial- such as PLOrk, SLOrk, BLOrk, L2Ork, LOLs, FLEA, and ized, launched and performed. The complexity of each HELO1, just to name a few, illustrate the passion many piece and skill of each performer can affect the amount of their respective ensembles have for this 21st century of time needed to prepare a piece for performance. And version of earlier experiments in technology-based group this “performance complexity” scales exponentially to the performance such as the Leauge of Automatic Music Com- number of laptops involved and the technical skill level posers and the Hub. [7] of the performers involved. Princeton’s laptop orchestra Typically, Laptop Orchestra composer-performers de- identified software configuration as perhaps one of their velop software to interpret human gestures through com- most significant problems. [11] puter interfaces that in turn control virtual instruments and processes that ultimately render music. Compositions can be improvised or scored, of determined or indeterminate 2. CHALLENGES FOR LOS length, with or without acoustic musicians. Laptops of- ten communicate across WiFi networks to synchronize While the interest in establishing Laptop Orchestras as a viable is seen in the rapid growth of 1In order, these groups are the Princeton LO, Stanford LO, Boulder LO, Linux LO, the LO of Louisiana, Florida Laptop Ensemble, and the such ensembles around the US and the world, the chal- Huddersfield Experimental LO. lenges of managing these groups are substantial. First and

460 Proceedings of the International Computer Music Conference 2011, University of Huddersfield, UK, 31 July - 5 August 2011 foremost is the distribution and maintenance of software compositions, preventing them from operating correctly. infrastructure. So a specific “de-configuration” script had to be created so that the computer would return to a neutral audio con- 2.1. Software and Version Control figuration after his piece was completed. Finally, the biggest challenge is the general demands There are a wide array of software environments available of concert performance. Imagine trying to prepare a lap- to composers and ensembles for the creation of music for top piece for performance. You need to be sure you have Laptop Orchestra. [15] [9] is a widely used graphical the right software, the right middleware, that all the pe- programming environment for MIDI, audio and video. Its ripherals were properly connected, and that you have the history is rich with applications for interactive computer correct computer configuration. And you have to do that music, and it is a language commonly used in the devel- for each laptop in the ensemble. And you have to do that opment of laptop orchestra music. Max can operate as an 8-10 times, depending on how many pieces you would interpretive application (i.e. running an application from perform on a concert. This quickly becomes a time prob- a user-defined document) or it can compile a standalone lem that is magnified exponentially by the techical savvy runtime application from a user-defined document. Max (or lack thereof) of the individual performers in the en- is a commercial program distributed by Cycling74 2. semble. ChucK [13] is an easy-to-use open-source audio pro- gramming language that runs scripts within a compiled virtual machine. It is a fairly lightweight environment to 3. A CONTEXT FOR GRID COMPUTING work with, especially because the programming is done through simple text files, and it has built-in hooks for man- In discussing these challenges with some of my colleagues, aging network communication using OpenSoundControl we realized that the laptop orchestra was in fact a grid (OSC) [14]. Both the Princeton and Stanford laptop or- computer for music. Grid computing is a form of dis- chestras have created a lot of LO music using ChucK, and tributed computing where a virtual supercomputer is cre- they have made these works available on the ChucK web- ated out of a loosely coordinated network of computers, site 3. Our group has used it, in large part, because it is all acting in concert towards a large common task. Grids very easy to get students started with the language. are largely comprised of heterogenous collections of com- There are plenty of other possible environments such puters, each connected to a common network, but not tied as SuperCollider [8], and composers are also creating works directly to one another in any synchronous way. [4] for laptop ensembles directly in programming languages Grids are used in all kinds of scientific applications, like Java. Jason Freeman’s LOLC is written in Java, and with the SETI@home [2] project being perhaps the best uses JSyn [5] as its sound engine. As well, some com- known. Here, participants in the project donate “down” positions rely on external peripheral devices such as Wii- cycles from their home computers for the purpose of pro- motes that require other middleware (i.e. OSCulator) to cessing radio astronomy data in the search for extraterres- translate data into OSC. trial intelligence. A central computer communicates with The point here is that Laptop Orchestras need to man- each computer, sending the networked machines bits of age a variety of core and middleware environments across data to process when they are not doing anything for the any number of laptop computers. This means checking to owner of the computer. The grid leverages available cy- make sure these environments are up-to-date AND mak- cles without tightly connecting processes across comput- ing sure that the compositions are compatible with those ers. particular software versions. That is, it is possible that a Laptop orchestras are also computer grids, although ChucK script might not be compatible with the most re- perhaps not at the same scale as SETI@home. Still, they cent version of ChucK, and so it is important to have ac- are a loosely coordinated group of computers tasked to- cess to both current and previous software versions. This wards the common goal of a musical composition. By is no easy task when dealing with one computer, let alone recognizing this, we are able to identify new kinds of so- five or twenty-five computers. lutions that can address the critical challenges posed by software version control, configuration and performance. 2.2. Configurations and Performance We have embarked on a project we call GRENDL, for GRid-ENabled Deployment for Laptop orchestras. This A second challenge is the variety of configurations that project uses the SAGA framework to build a command- are used for laptop ensemble music and the likelihood line application that manages laptop orchestra configura- that such configurations could conflict with one another. tions and provides controls for the performance of music A specific instance of this happened with our group. A composed for these ensembles. composer wanted to use the audio driver Soundflower to reroute an audio stream generated by a command-line ap- plication into Max. The problem was that when he was 3.1. GRENDL done, his specific audio configuration interfered with other The GRENDL project builds off the premise that laptop 2http://www.cycling74.com orchestras are, in fact, computational grids for music. It is 3http://chuck.cs.princeton.edu an integrated system that deploys, manages, and controls

461 Proceedings of the International Computer Music Conference 2011, University of Huddersfield, UK, 31 July - 5 August 2011 software and hardware technologies needed for the perfor- tor runs the quit mode. Like launch mode, GRENDL runs mance of music for laptop orchestras. For any LO compo- scripts on both the master and client that shut down the sition, it links digital artifacts (e.g., scores, software, phys- software that was previously launched. If there are spe- ical devices) with middleware applications (e.g., ChucK cial configurations created for the composition, program- [13], Max [15], OSCulator [1]) specific to the hardware mers can use the quit mode to re-establish the baseline devices and operating systems available for performances. configuration so that the next composition can start at that GRENDL works like a music librarian for the orches- baseline. tra, distributing the appropriate music to all of the musi- cians for a concert in advance of that concert. GRENDL 3.2. Software Integration also provides the conductor with the correct scores for each piece on the program, and gives the conductor the As with any grid computing environment, there must be ability to start and stop a performance. GRENDL supports an integration between the command architecture and the both major phases of the performance process, using one various frameworks and compute software that comprise of three modes of operation. the grid. While we have had real successes with our first version of GRENDL, we encountered challenges when linking GRENDL’s control messaging and frameworks to the music frameworks generally used in LO compositions (i.e., Max, Chuck).

3.2.1. SAGA

The Simple API for Grid Applications (SAGA) [6] is a grid computing framework that helps manage distributed applications in complex environments. SAGA connects application software written in C, C++ or Python with grid-based middleware services for distributed comput- ing, allowing scientists a robust and platform neutral frame- work in which their simulations can take place. While SAGA was developed for high performance scientific ap- plications using large grids of hundreds or thousands of computers, it has proven to be a natural fit for the laptop orchestra environment. Figure 2. GRENDL includes three processing modes. The transfer mode is used to move information between repository and laptops. Launch mode ensures that nec- essary software is loaded and configured for each piece. Quit mode shuts down any applications and allows for the reconfiguration of the operating system.

TRANSFER MODE: Prior to the concert, GRENDL is used to transfer all files from a central repository (local- host or SVN repository), running pre- and post-transfer configuration scripts (if needed) on the master computer, and running configuration scripts on the client machines after file transfers have been completed. The conductor can start the transfer process from the command-line or Figure 3. SAGA provides access to grid middleware ser- use cartouche tangibles to identify which “scores” should vices from common programming languages. be transferred. LAUNCH MODE: During concert, the conductor be- gins each piece using the launch mode. Here, GRENDL Much of GRENDL’s functionality for the preparation runs any pre-launch scripts on the master computer (i.e. phase of the performance is supplied by SAGA. This in- sync scripts), sends a “start” command to all computers cludes support for configuring laptops, distributing com- in the orchestra, and runs post-launch scripts (if needed) positions and supporting software, and launching the en- on the master. Cartouche tangibles tell client computers vironment for each piece in the program. Since SAGA’s who is performing on them and what their “role” is (i.e. synchronization mechanisms are event-driven rather than percussion, voice). Cartouches may also contain perfor- time-based, it provides an ideal infrastructure for the asy- mance graphics for the musicians to use as a score. chronous and variable latency activities typical of perfor- QUIT MODE: After a piece is finished, the conduc- mance preparation.

462 Proceedings of the International Computer Music Conference 2011, University of Huddersfield, UK, 31 July - 5 August 2011

3.2.2. Music Applications in public-resource computing,” Communications of the ACM, vol. 45, no. 11, pp. 56–61, 2002. For the LO grid to work, LO compositions must be able to respond to messages from the grid controller. In our [3] S. Beck, C. Branton, S. Maddineni, B. Ullmer, and case, GRENDL passes messages to the software frame- S. Jha, “GRENDL: Grid Enabled Deployment for works used in each composition through shell scripts. For Laptop Orchestras,” in Society for Electro-Acoustic example, a launch command for a Chuck-based composi- Music in the United States 2011 National Confer- tion would be a shell script that changes directory to the ence. SEAMUS, 2011. location of the Chuck code, and uses Chuck’s shell com- [4] F. Berman, G. Fox, and A. Hey, Grid computing: mands to launch the Chuck VM with the needed code file. making the global infrastructure a reality. John Max-based compositions pose specific challenges in Wiley & Sons Inc, 2003. this context. The Max application does not respond to Ap- plescript nor shell scripts directly. In order for Max-based [5] P. Burk, “Jsyn-a real-time synthesis api for java,” LO software to work in GRENDL, users must create a in Proceedings of the 1998 International Computer compiled Max application which can then be launched Music Conference, 1998, pp. 252–255. from the Finder via Applescript. Quitting Max-based com- positions is also somewhat awkward, requiring scripts to [6] T. Goodale, S. Jha, H. Kaiser, T. Kielmann, P. Klei- kill the process for the compiled application. While this is jer, A. Merzky, J. Shalf, and C. Smith, “A simple not an ideal scenario, it highlights the various challenges API for Grid applications (SAGA),” in Grid Forum LOs face in automating these processes. Document GFD, vol. 90, 2007. [7] S. Lancaster, “The Aesthetics and History of the 4. FUTURE CONSIDERATIONS Hub: The Effects of Changing Technology on Net- work Computer Music,” Leonardo Music Journal, The current success of GRENDL has led us to consider vol. 8, pp. 39–44, 1998. new and innovative tools that could be adapted to our grid [8] J. McCartney, “Rethinking the computer music lan- computer for music. Specifically, we are exploring the use guage: SuperCollider,” Computer Music Journal, of tangible interfaces [12] as a method to make computers vol. 26, no. 4, pp. 61–68, 2002. in a laptop orchestra more self-aware. The challenge here is that for compositions where a [9] M. Puckette, “Max at seventeen,” Computer Music specific person has a specific role or task to play in a com- Journal, vol. 26, no. 4, pp. 31–43, 2002. position, that person is likely tied to a specific computer. [10] D. Trueman, “Why a laptop orchestra?” Organised In an ideal situation, any player with any role should be Sound, vol. 12, no. 02, pp. 171–179, 2007. able to play any laptop. We see the use of tangible objects as a way of allowing laptops in the grid to be aware of [11] D. Trueman, P. Cook, S. Smallwood, and G. Wang, who is “playing” them and what their role is in the com- “PLOrk: Princeton laptop orchestra, year 1,” in Pro- position. Imagine that a performer brings a RFID-encoded ceedings of the 2006 International Computer Music card (or “cartouche”) to a laptop. An RFID reader would Conference (ICMC). Citeseer. know which card the performer had, identifying them to the GRENDL system. By doing this, composers and per- [12] B. Ullmer, R. Sankaran, S. Jandhyala, B. Tregre, formers would not need to worry about whether a per- C. Toole, K. Kallakuri, C. Laan, M. Hess, F. Harhad, former was at the correct laptop, and the conductor could U. Wiggins et al., “Tangible menus and interaction use cartouches as virtual scores, communicating transfer, trays: core tangibles for common physical/digital launch and quit commands at the push of a button (rather activities,” in Proceedings of the 2nd international than at the command line). conference on Tangible and embedded interaction. Returning to the “orchestral” metaphor, GRENDL will ACM, 2008, pp. 209–212. serve as both music librarian, stage manager, and conduc- [13] G. Wang, P. Cook et al., “ChucK: A concurrent, on- tor for laptop orchestras. We anticipate the use of such the-fly audio programming language,” in Proceed- tangible interfaces will lead to new and novel devices that ings of International Computer Music Conference. will further accelerate the acceptance of laptop orchestras Citeseer, 2003, pp. 219–226. as a legitimate musical ensemble. [14] M. Wright and A. Freed, “Open sound control: A new protocol for communicating with sound syn- 5. REFERENCES thesizers,” in Proceedings of the 1997 International Computer Music Conference, 1997, pp. 101–104. [1] http://www.osculator.net/. [Online]. Available: http: //www.osculator.net/ [15] D. Zicarelli, “How I learned to love a program that does nothing,” Computer Music Journal, vol. 26, [2] D. Anderson, J. Cobb, E. Korpela, M. Lebofsky, no. 4, pp. 44–51, 2002. and D. Werthimer, “SETI@ home: an experiment

463