Composing for Laptop Orchestra

ion. Downloaded from http://www.mitpressjournals.org/doi/pdf/10.1162/comj.2008.32.1.9 by guest on 30 December 2022 Smallwood et al. 15 with a wired network). Even in good situations, however, packets are occasionally dropped, and composers need to build a certain amount of protection into their programs if this is likely to cause problems. For instance, if it is important for all the machines to be on the same beat in, say, a 16beat cycle, the conducting machine should send the beat number over the network and not simply a pulse; this will ensure that if a packet is dropped to a par ticular machine, it will not get out of phase because it is locally counting pulses. Also, if particular messages are crucial, it is essential to have them paired with subsequent messages that ask for message receipt confi rmation. We are hopeful that the need for such strategies will be minimized in future versions of our network. Ge Wang’s CliX (see Figure 8) makes use of two different kinds of conductors. A conductor laptop sends rapid pulses over the network; these pulses effectively quantize the events generated on each machine. The players type, generating pitched clicks (the pitches are dependent on the key struck; for instance, it is possible to play a chromatic scale by typing the alphabet), and their clicks are then being part of the system. Beforehand, each player created a sound that is part of a bank of 19 sounds, and their job in performance is to “intend” for the system to become biased towards the sound that they created (see Figure 7). Needless to say, such research has its skeptics, and several researchers have had diffi culty replicating the PEAR laboratory results. (See skepdic.com / pear.html / for a summary of some of these issues, and see Hansen, Utts, and Markwick [1991] for a critique of related work from the lab.) Because of this, some of the more scientifi cally minded members of PLOrk had diffi culty accepting the approach, though they nevertheless attempted to perform the piece in good faith. Networking and The Conductor The network can be a powerful conducting tool and also facilitate the design of a kind of macroinstrument with the orchestra. Information that can be passed along the network is quite different from the kind of information traditionally conveyed by a conductor. Thus, possibilities for coordination, messagepassing, group control, quantization, tempo, dynamics and so on are on the table for all composers working with PLOrk. Should these tasks be given to a conductor? Should the conductor be human, or should it be a program operating over the network? Or should there be both kinds of conductor? The ability to tightly synchronize the ensemble via the network is remarkable, though not fl awless. It is practical and easy to have a single “conducting” computer send a sequence of pulses (e.g., Max bang messages or similar) over the network to control rhythmically timed events, and in our experience, the timing is more than tight enough for very small pulsewidths (on the order of 40 msec or so). In most situations, we found the wireless network capable of maintaining a constant, “hiccupfree” pulse without diffi culty, though in some situations this was not the case (perhaps owing to heavy local wireless traffi c from other networks), and we are exploring ways to make our network more robust and immune to interference (including working Figure 8. Ge Wang con-