Douglas Geers
Research: Juicer

front page | main research page | bio | music | contact info


NOTE: THIS IS AN OLD WEBPAGE, created in 2001. Please see my current research page for up-to-date information about my projects and software.


2. Juicer: An Environment for DSP Performance
Figure 1: Main Juicer interface
 I am currently completing a composition project entitled `Gilgamesh`. This work is an hour-long theatrical multimedia work for violin, live signal processing, pre-composed electroacoustic music elements, interactive mechanical sculptures, video, and puppetry. This paper intends to discuss the aims and general design of the digital audio processing (DSP) system used in `Gilgamesh,` which I have named the `Juicer` (Figure 1).

The purpose of the Juicer system is to provide an integrated system for managing the electroacoustic elements of `Gilgamesh.` This includes playback of pre-composed computer music, sampling microphone input for playback later in the work, playing those and other samples in synchronization with microphone input, and management of an array of DSP modules (nine in all). The entire Juicer system was created in the Max/MSP environment.

The DSP portion of Juicer consists of (1) nine signal processing modules which are interconnected in a highly reconfigureable way, (2) an interface for adjusting or performing DSP in realtime, (3) a simple method for programming preset combinations of effects and their parameters, and (4) the ability to `morph` from one setting to another over a specified period of time.

Although it was created specifically for performance in `Gilgamesh,` the Juicer system was designed in a modular fashion in hopes that many of its elements and possibly the entire system will be useable in future projects. In fact, nearly everything visible on the main Juicer interface is the `face` of a separate module. Each module of the system was built as a separate Max/MSP patch and then imported into the final interface via the `bpatcher` object. Moreover, within each module the interface and `engine` of the processing mechanism were separated. Thus the final interface presents a large, orderly, easily modifiable array of controls and none of the necessary but visually distracting processing algorithms (Figure 1.)

However, although the interface presents a wide array of sliders, pop-up menus, buttons, and number boxes for activating and adjusting all of the DSP modules, it would be quite a complicated task for one to regularly update the values in each of these in a coordinated fashion in order to follow a composed score of effects implementation. To drastically simplify this task during a performance, a deceptively simple interface named `DSP Presets` is the facade for a command center that activates preprogrammed effects configurations and controls movement from each one of these to the next (Figure 2.)
Fig. 2: DSP Presets Interface

The DSP Presets interface has essentially three controls: (1) a number box, increment arrows, and pop-up menu, each of which can increment to the next effects preset from a list created earlier; (2) a pop-up menu to allow the user to select the morph time between the previous preset and the new one; and (3) a "Go!" button, which initiates the morph. Thus, the user simply chooses the next preset, sets the desired morph time, and then at the appropriate moment in the music s/he hits the "Go!" button to initiate the smooth morph to the new preset’s effects configuration. Each preset number in the list is associated with data (in a coll object) which lists the status and settings of each DSP module for that preset. The DSP Presets module uses `line` objects to send intermediate values to each module until the destination value is reached, and the rate that these are sent is controlled to match the user’s desired morph time.

Since all of the connections in the chain of processing modules are software links, the order in which the effects are used can change from preset to preset, which is quite satisfying and allows for a wider range of sonic mixtures. One must be careful, of course, when changing the ordering since the sudden re-ordering can cause sudden changes in the signal level going into the currently active modules, resulting in an annoying click; but when managed intelligently this can be avoided.

One limitation of the system is that the configuration data for each preset must be typed into the patch by hand, which is not ideal but can still be done `on the fly` while performing with the Juicer. It would be preferable to integrate some kind of `snapshot` element into the system so that the user could add presets whenever s/he found something especially satisfying. However, it seems that this would be relatively complex to implement in Max and thus has not been included.


Other examples of my research include Appliance, a system for interactive performance with sculptures; Ripples, a stochastic composition system; and Treembre, an attempt to hierarchically organize elements of timbre and animate them in time.



  • A brief bio of Doug
  • Go to Doug's front page


    All music and visual images on this website are protected by copyright and may not be used without the expressed written consent of Douglas Geers. © 1999 Douglas Geers.