• My short paper “DIY Hybrid Analog/Digital Modular Synthesis” – which covers the USB-Octomod, tabulaRasa, and snake.corral –  has been accepted for NIME 2012, and I will present a poster version at the conference. The conference runs from May 21 – 23, in Ann Arbor, MI.
• I will perform 4/27 at UCSD and 4/28 as part of the California Electronic Music Exchange Concert series.
• Finally, I’ve started posting some live coding videos:

96 Independent Parameters

I recently spent a few hours putting together a preset manager in Pure Data. The above image shows a set of controls for 8 independent (but identical) signal processing channels. Clearly, 96 parameters is too many to realistically handle in performance, so I needed some way to store and recall settings. As shown in the image, each parameter has a [receive] object which listens for messages of a specific type. Then, a [route] object filters out all messages except those meant for that specific parameter instance.

Here’s the object preset-manager.pd - though it will take a decent amount of modification to get it to work for another patch.

The preset manager interface.

Above is the preset manager interface. A particular slot is accessed via the number box, and that slot can be read or written to with a message box.

Innards of the preset manager object.

Here are the innards of the preset manager object. The block on the right stores presets, and the block on the left recalls them. Presets are stored as raw text files, named with sequential numbers, and are formatted like this:

filter-bypass 1 1 1 1 0 0 0 0;
filter-rate-mod 0.02 0.81 0 50 0 0 0 0;
filter-rate 0.22 0.66 0.95 106 0 0 0 0;
am-bypass 1 1 0 1 0 0 0 0;
am-width 0 0.5 0.52 87 0 0 0 0;
am-rate-mod 16 0.38 0.54 46 0 0 0 0;
am-rate 2.02 1.48 2.54 3.83 0 0 0 0;
fm-bypass 0 0 0 1 0 0 0 0;
fm-rate 173 97 25 1.64 0 0 0 0;
fm-pos/width 55 64 108 96 0 0 0 0;
fm-mode 2 2 2 1 1 0 0 0;
fm-register 1 0 2 2 1 1 1 0;

Each parameter type is followed by eight values – one for each channel. The [textfile] object works really well for reading and writing text files line-by-line.

Code for writing a preset.

Code for reading a preset.

Gates (No. 1) is a software instrument, programmed in Pure Data. Inspired by other instrument builders, particularly David Tudor’s electronic instruments, Gates (No. 1) provides the performer with high-level control of musical events, while the moment-to-moment details emerge from the patch itself.

The main interface for Gates (No. 1).

Central to the sound of the instrument is a set of three feedback networks. Implemented using recursive delay lines, each network emphasizes a particular frequency range: low, medium, and high. The frequency ranges are user-selectable, allowing for coarse control over the register of a particular musical event. Slight changes in delay time and filter cutoffs destabilize the feedback, producing glissandi and other effects.

Feedback network producing low frequency sounds.

The pitch register is selected through a combination of key-presses, which also determines other parameters of the sound. The first of those other parameters is a selection of one of 6 sound-processing algorithms which is applied to the selected feedback network. The 6 processing types are: amplitude modulation by line segments, ring modulation by filtered noise, ring modulation by a sine wave, recursive delay with delay time modulation, a chorus effect, and a set of bandpass filters in series (creating phase cancellations).

ASCII-based input module.

Inner workings of the patch. Above are the different processing modules, routed through an echo effect, and out to the DAC.

The second parameter is a selection of one of 50 different, hand-drawn wave shapes. The wave shapes provide control data for the modulation sources described above.

One set of wave shapes, used to control the sound processing modules.

The key-press combination also determines the duration and number of repeats of a sound, ranging from short, repetitive events to long drones. Finally, the performer can choose to route the output of the instrument through a secondary processing unit, which modifies its processing algorithms according to the rhythmic onsets of the generated sound.

The secondary effects module adds a layer of digital grit, contrasting with the cleaner sounds of the instrument.

The variety and diversity of sound generation, processing, and control algorithms ensure that the instrument is never fully under the control of the performer. Rather than a flaw, this is a feature, as it ensures an exciting challenge for the performer, and produces performances which can retain similar characteristics while varying widely in structure and duration.

Christopher Burns and Greg Surges Live Coding – 12.11.2008 from Greg Surges on Vimeo.

As you can see (in the code available here), the function takes three arguments. These are generic arguments, used in the *_new() function of every external you’ll write. The arguments are as follows:

t_symbol *s – a pointer to the symbolic representation of the objects name. You don’t have to worry about this, it’s for PD.

int argc – the number of arguments the user has entered, following the name of the object.

t_atom *argv – a pointer to the first of these arguments.

You’ll use argc to tell you how many arguments to read, starting from the argv pointer. This allows you to create an object that uses default values if a user doesn’t enter all of the required arguments.

In randomwalk.c, I’m using a switch statement to check the number of arguments provided, and then read the user-provided arguments into their proper variables. The atom_getfloat() function simply takes one of the arguments (of the PD type atom) and returns a C/C++ float, which can be assigned to a variable.

Below that, I reuse the argc count to determine which variables have to be assigned to defaults. Finally, I do some error checking to make sure that the highbound is actually a higher number than the lowbound, and swap if needed. This kind of error checking is very important to avoid crashes when actually using the object.

Finally, we have to assign inlets and outlets. The three calls to floatinlet_new() assign inlets which allow direct assignment of the lower, upper, and step variables from PD. There should probably be some error checking here too, because what would happen if a user input a list or a symbol instead? We also define f_out to be an outlet, using outlet_new() which takes two arguments, a reference to the object itself, and the type of value that will be output.

The return statement simply returns the initialized object to PD, ready for use.