Notice: add_custom_image_header is deprecated since version 3.4.0! Use add_theme_support( 'custom-header', $args ) instead. in /var/www/html/shows/wp-includes/functions.php on line 4334 ITP Spring Show 2008 » The Arboretum
-->

The Arboretum

Joseph Mariglio
Michael Craig Clemow

The Arboretum is a homemade supercomputer, designed for making music.

http://deadlylittlepills.com/arboretum/index.html

Classes Frameworks for Interactive Sound

The Arboretum is (at least at present) a network of 13 Linux-based computers, connected by a network. There is one "server,""head" or "queen" node, which acts as a gateway for the 12 "client,""compute," or "worker" nodes. The sound-card output of all of the worker nodes (and the server node) is mixed together on a mixing board. You can think of the worker nodes as musicians and the head node as a conductor, if you like. Sometimes we do.
A parallel architecture in a sound-making context allows us to execute computationally intensive tasks in a shorter amount of time. To prove our point, we will re-synthesize a recording of a participant's voice using spectral grains (very small audio pieces) derived from some other sound source, such as a teakettle, a cat's meow, or the sound of shattering glass.

Background
We're following a fairly well-established computer music tradition, in which Curtis Roads is a huge figurehead. Utilizing the ubiquity and the power of the computer to make sound has a long history. Parallel computing, however, has played a relatively smaller role in this field than it has in that of its visual cousin.

Any research into the field of compute clusters and "Beowulf" supercomputers will lead you inevitably into a world of optimizations and engineering principles, requiring knowledge of low-level tools and system design theory that would usually scare off even the most intrepid sound designer or artist. We have declared a sort of "renaissance" in distributed computing and decided to dispense with the formalities of engineering practice to embrace an attitude more suited to rapid prototyping of software with higher level tools. We substitute ChucK, SuperCollider and Python for C and OSC for MPI or other low-level message passing schemes.

Audience
While our target audience for the end of this project will be anyone who wants to make and enjoy music and sound using new technology, in its current state we realize that our project will mainly interest people who are already interested in computer music or from an engineering perspective, people whose interest lies in the use of clusters for computing purposes. For others the demonstration of the power of such a system will remain a curiosity and, we hope, a memorable one.

User Scenario
To demonstrate the power of the system, we will take a voice sample from an interested participant and re-synthesize the recording using a technique known as "Granular Synthesis." The source material for the re-synthesis can be any other sound (e.g. a cat's meow, the sound of broken glass).

Implementation
The hardware consists of 6 Pentium-4 based machines with at around 1Gb of RAM each and 7 AMD Athlon XP machines with 256Mb of RAM a piece. One of the P4 machines is the server node, managing the others. One of the AMD machines is our database server, which is designed to be used for data set sonification projects.

On the software side is a technology stack created from open source projects: 64Studio - a Debian-based multimedia Linux distribution highly optimized for low-latency audio, SuperCollider - a mature and powerful high-level audio synthesis language derived from SmallTalk, and ChucK - a newer live-coding audio language being developed at Princeton. The system's concurrency model uses Open Sound Control (OSC) as a message passing protocol over a closed fast ethernet network. Custom built software will do the actual re-synthesis of the participant's voice. This algorithm is mainly written in SuperCollider at present.

Conclusion
While parallel computing multiplies the power of your software by distributing the load across multiple processors, it also multiplies the designers' problems by the same factors. The amount of time that was required just to set up the hardware was shocking. Also converting algorithms to run across these machines on a network proved fairly tough. While ChucK was primed for this environment, the older SuperCollider required a bit of trial and error. Administrating the network also proved to be orders of magnitude more complex than just administrating a single computer. We hope the payoff is worth the effort. We think it will be.