I've been long interested in the imprint left on objects by communications tools of relatively new technology. A great quantity of software is freely (and/or easily) available for composing/producing music, each environment imposing its own set of constraints on the methods used to produce the result. Part of my interests lie in using software capable of digital processing at a relatively low level (that is, relative to software for producing "music"), and exploiting this capability to experience sound from what is to me a new perspective. I find that working with sound tools from this frame of reference allows the compositional/performance experience and its output to both comment on each other, and in my current design I use several simple components to explore these goals in an improvisational environment.

In exploring alternative ways to synthesize and access buffers of familiar sounds, unexpected results abound. In attempting to find new sounds, I am often dealing with constructions of sound modules, the modules held together in such a fragile way that for every one fragment of interesting material, I have ten fragments that are unusable or will crash the software's DSP engine. In some ways this is a reflection of my own style of working, and it will most always be present in some form or another in what I produce.

I decided to explore ChucK as an environment for live performance. In learning the language, I would not only come across sounds that I would decide to use, but also determine a somewhat reasonable way of organizing a performance. FM synthesis is a strong interest of mine, and forms the basis for some of my structures. Other interests here the use of re-sampling the performance's output to achieve a particular textural aesthetic.

ChucK is run by running the executable (the ChucK VM), and then sending it scripts, which it will compile and execute a running process. The unit generator objects, UGens, are assigned parameters and DSP connections by means of the "chuck" operator (=>). This mimics the common "source-->processor" signal-processing concept. Parameters are also assigned in this reverse manner:

UGens are "ticked" by writing code to advance time. now is a keyword to which a time or duration can be "chucked" to advance now by a specific amount:

This will tick any active UGens the necessary number of times for the current samplerate, but code after this line will not be executed until the duration has elapsed to now. Sample-accurate calculations, such as would be desirable for FM, are also possible (but of course involve more calculations):

The third statement with two chuck operators looks like a serial assignment, but the operator can also be used to assign and "pass on" the value, in parallel fashion, to multiple UGens. The blackhole keyword is a connection that will tick a UGen, but not output it to the dac. Without this connection we would not have any sample output from the modulator.

I had a rough planned duration of 15-20 minutes. I knew also that I would be dealing with textural sources, as the organization, editing and launching of scripts in a live context would make it more difficult to maintain tight gestural control of processes without a lot of pre-defined MIDI-triggered scripts. I planned to limit the use of MIDI to general probability controls.

I have two main FM scripts that follow this general structure:

<global variables>
<synthesis function definition>
<main loop>
   <receive any new MIDI control data>
   <probability evaluation loop>
      <launch new function instance>
   </probability evaluation loop>
</main loop>

By this structure, both the synthesis function and control code are launched from the same script file. The control code does not control synthesis parameters, but rather the likelihood of launching a new instance of the synthesis code at some regular interval. This instance could also be called a "voice". I also make use of a control parameter to adjust the maximum possible duration of new voices. With this simple mechanism of only two controls, duration and probability, I surrender a finer level of control over what is going on, as the response time of this system is determined by this duration value. I can change the settings of the synthesis function, but not without launching a new script. ChucK makes it easy to either add to or replace existing processes by giving every process a unique ID.

Another component of this performance experiment is the capability to easily record short segments of ChucK's output to WAV files on disk, and then load these into buffers which are accessed in different ways. I have timing controls which will, at some determined interval, generate random playback speeds from multiples within a given range, such that the output speeds will be harmonically related.

This "scrubber" script also accesses the buffer data by means of an oscillator output, multiplied by a scalar to point to a specific sample index. This function runs according at a variable sampling rate. The general construction of the scrubber is more clear as outlined in a diagram:

ChucK, being in an early stage of development, is not terribly efficient - and given its conceptual merit, application and its authors' intentions, this is not a top priority of the development team. On a 1.5 Ghz G4 running OS X, I had to be careful about which scripts I was running at the same time, and grew accustomed to the limits of the system.

When only making use of the simpler UGens such as the basic oscillators, the significant factor contributing to a script's CPU usage is the number of calculations performed within a given amount of time. Specifically, this is how often we are advancing time in between making calculations. It is not possible to simply chuck any signal output to another UGen parameter (as is common in an environment/paradigm such as Max/MSP), even if it can be manually "patched" by running a loop at the sampling rate. There happens to be feature recent to ChucK that allows UGen-to-UGen sync connections to control frequency or phase, but I found this direct patching method too limiting for my FM operations. Instead, I am performing the FM operations manually, but at a 2-millisecond rate, which affords me the "polyphonic" implementation. It's a little dirty, but I like it.

In my learning of ChucK, I concentrated my efforts on developing and refining several simple scripts for use in live performance, and find that there is still a high degree of variability in the output of a session. This results especially from the use of the recorder/scrubber scripts, with which I can control general speed and timing constraints of sample playback, but still retain a high unpredictability of pitch and timbral qualities.

This environment brings about new possibilities where a great amount of control, especially over time, of audio processing is desired. For my interests, I've enjoyed the simplicity of its design and the capability to try new ideas and hear the results instantly. Great work team!