Mushroom Ð An Oracular Sound Processor
Eric Lyon
Dartmouth College
http://arcana.dartmouth.edu/~eric
Composers of digital music today have a bewildering variety of sound-processing tools and techniques at their disposal. At their best, these tools allow composers to hone a sound to perfection. However, they can also lead us into a routine which bypasses avenues of experimentation, simply because the known tools work so well and their sonic output is so attractive. An alternative strategy is oracular sound processing. An oracular sound processor creates a derived version of its input whose characteristics could not have been fully predicted, while affording the user little or no parametric control over the process. Thonk [1] is a good example of an oracular processor. Mushroom is another such processor.
Mushroom controls and archives hierarchical, sequential processing of sound. Central to the operation of Mushroom is the reduction of processing to its most basic components - input and output sounds. Mushroom requires that all processes be implemented in terms of input and output, with any parametric choices made internally by the process. For example, if a process ring-modulates a sound, it must also algorithmically select the ring-modulation frequency. This requirement makes all sound processes interchangeable. The crux of MushroomÕs work is to assemble a random sequence of these processes and apply that sequence to an input sound, creating an output sound.
Random sequential processing of sound is the basic operation of Mushroom. In its simplest model, an input sound is presented to Mushroom, which selects a random series of processes, applies them to the input sound, and produces an output sound. This itself is quite useful as a one-shot oracular process. However Mushroom provides further operational structure. Rather than specifying an input sound and receiving a single output sound, the user specifies an input sound, a desired number of output sounds, and the processing level. Each of the derived sounds will be created from a different random sequence of processors. The processing level is based on the idea of a familial relation among derived sounds. The original input sound is defined as level 0. All sounds derived directly from this sound are at level 1. The first run of Mushroom on an input sound must be at level 0. After that run, there exists at least one derived sound at level 1. Requesting a new Mushroom run at level 1 results in Mushroom randomly selecting a sound from all level 1 sounds, and creating a new sound at level 2. That process is repeated for the requested number of output sounds at level 2. At higher levels, the sounds are more highly processed. They are less recognizably related to the original input sound, but they collectively embody complex sonic interrelations among all the sounds at the different levels. These relationships are then available to the composer to contemplate and perhaps exploit.
In addition to the basic operations described above, Mushroom implements a few conveniences. Since Mushroom archives all processor sequences, the user can discover how any sound was created at any level. By calling a utility called Mushmimic, the user can specify a derived sound, and request that Mushroom apply the sequence of processors that generated the derived sound to a new input sound. Mushroom also facilitates deleting unwanted derived sounds, which then become unavailable for further processing.
Implementation
Mushroom is written in Perl, and runs on Linux or any other Unix system. The Mushroom Perl scripts are designed to operate on a given input sound in a directory. The program first looks in the current directory for preference and processor files, and creates them if they are not found. The preference file specifies how many processors to run in a single random sequence. The default is three. The processor file contains a list of available processes. Once this information is loaded, Mushroom begins to create derived sounds. First an input sound is selected. If the run is at level 0, this will always be the original sound. At any higher level, an input sound is randomly selected from available sounds at the next lower level. Then a series of processes is selected from the processor list. Finally, the processors are applied by calling Perl functions named after the processes.
As an example, suppose the first process selected is rev1. This is the function that calls rev1:
sub rev1_mproc {
local ($insnd,$outsnd) = @_;
`rev1.pl $insnd $outsnd`;
}
Mushroom knows nothing about the Perl script Òrev1.plÓ except that its two parameters are Òname of input soundÓ and Òname of output soundÓ. The script Òrev1.plÓ must exist in some directory where Perl can find it. Here is Òrev1.plÓ:
#!/usr/local/bin/perl
$HOME = $ENV{"HOME"};
require "$HOME/PERL/libperl.pl";
($insnd,$outsnd,$dry,$tail,$gain) = @ARGV;
defined $outsnd || die "insnd outsnd [dry tail gain\n";
#SET DEFAULTS IF UNDEFINED
$dry = $dry || .3;
$tail = $tail || 1.5;
$gain = $gain || 1.0;
# PATH OF THE Csound ORC
$proc = "$CSDIR/REVERB/rev1";
$nchans = &getchans( $insnd );
if($nchans == 2 ){
$instr = "i1";
} else {
$instr = "i2";
}
$snddur = &getdur( $insnd );
$dur = $snddur + $tail ;
$score = $proc . ".sco";
# CREATE Csound SCO
open( SCORE, ">$score");
printf SCORE "$instr 0 %.5f 1 0 %.5f %.5f %.5f .01\n",$dur, $gain, $dry, $snddur;
close( SCORE );
#RUN Csound TO GENERATE PROCESSED SOUND
`csio.pl $proc $insnd $outsnd`;
Note that this script is not autonomous, but relies on other scripts and processes. This reverberation process is implemented in Csound. But other processes are implemented in C, and could also be implemented in any acoustic compiler that does not require interactivity or communication through a GUI. The various programs used in even a single process may be scattered all over the system, but Perl brings them together and Mushroom harvests the results.
It is easy to add new processes to Mushroom. First one creates a script which performs processing, and whose only parameters are input and output soundfile names. Second, the name of that process is added to the processor list. Third, a calling function is added to Mushroom. Suppose we create a processor script that stretches a sound, and call it Òstretch.plÓ. We add the word ÒstretchÓ to the processor list and create a calling function named Òstretch_mprocÓ which looks like this:
sub stretch_mproc {
local ($insnd,$outsnd) = @_;
`stretch.pl $insnd $outsnd`;
}
WeÕre done, and now stretch is available to Mushroom as a process that may be randomly inserted into a sequence.
I have used Mushroom primarily to generate sounds that are then deployed in tape music through traditional mixing methods. There is also a stripped down version of Mushroom written for Max/MSP that is limited by the real-time computational capacity of the computer. Finally, I designed a web site where visitors could create apply Mushroom to synthetic sounds. There are many other possibilities for sound installations and not-quite-real-time streaming projects. The design for Mushroom could also be modified to incorporate various forms of expert knowledge, and could work in conjunction with a database that automatically extracts salient features from derived sounds.
Mushroom is a highly effective and enjoyable oracular sound-processing tool, creating complex sounds that have found their place in my own compositional work. There is a characteristic Mushroom ÒsoundÓ which is highly processed. However the specific nature of the sound is entirely dependent on the available processes which Mushroom deploys. Through adding and deleting available processes the behavior of Mushroom may be personalized while still preserving its oracular function.