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