gen~: The Garden of Earthly Delays

After doing a quick tutorial at the Cycling ’74 Expo, it became clear that lots of people out there were really surprised and happy to discover that they didn’t need to be a supergenius to have fun with the gen~ object. While the new Gen stuff is as elegant and powerful as the day is long, you can also have quite a lot of enjoyment with a very few objects. So here’s a sequence of little patches that I hope will give you a window into having some audio fun without scaring the bejeepers out of you. These patches are not impossibly complicated, or efficient or elegant – they’re the product of someone at play. I hope they encourage you to play, too. I even added some simple presets to spur your imagination.

All tutorials in this series: Part 1, gen~: The Garden of Earthly Delays, Part 2a: The Joy of Swiz, Part 2b: Adventures in Vectorland

Gen need not be Rocket Surgery (although the Rocket Surgeons will find much to enjoy, I’m sure), but there are a few simple things that it’ll help to know when looking at these patches.

1. The flow of data inside the gen~ object is like MSP in that it’s synchronous, but instead of thinking of performing some action on a block of samples, we’re working with one sample at a time - which lets us do things with single-sample feedback that we could never do before.

2. The flow of data inside the gen~ object is constant – there isn’t anything like a trigger, for example. It also means that gen~ operators are always sending something out – a signal sample value, a parameter value, or the result of a test of some kind. We need something special that lets us control our patch with messages from the “outside world.” In the Gen world, we have the param (parameter) operator to do that. You’ll see it in use here.

3. Since data is always synchronous, a feedback loop isn’t really possible. Instead, we have an operator called history that acts like a single-sample delay that lets us create feedback loops for useful things like data smoothing and… well… feedback.

4. One difference you may notice between Gen objects and their Max cousins has to do with the relationship between arguments to a Gen operator and the number of inlets the operator has. Unlike Max object, using arguments to specify an initial value for a Gen operator changes the number of inlets an object has – that’s because those initial values cannot be changed once specified. Here’s a simple example of that relationship using the mixer object, which we’ll be making good use of in just a minute.

Ring Tones

Okay. Let’s get down to business!

This tutorial is going to be about manipulating delay lines. Since the gen~ object gives us access to audio on a per-sample basis – and thus lets us set feedback loops that are tighter than the signal-vector variety that MSP provides, there’s a lot of room for creating new sounds.

The first patch drive-by1a.maxpat, demonstrates a few simple features of working with delays (using the delay operator):

Like the MSP tapin~ object, the delay operator at the heart of this patch takes an argument that specifies the length of the maximum delay possible (remember that since we’re working with gen~, that amount is specified in samples). Although the delay operator can take a second argument to set multiple taps, we’ll only need one delay line each for the left and right channels of our stereo gen~ patch. You might want to investigate that for yourself later on.

The other crucial piece of our patch is the mix operator. It not only lets us mix the wet and dry signals for output, but it introduces a way of smoothing data that gen~ aficionados use everywhere. The mix operator takes two input values in the first two inputs, and then outputs an interpolated value based on a value between 0. and 1.0 received in the right inlet. And of course, it works on one sample at a time.

You’ll see the mix operator used in two places – to handle the wet/dry mix of the delayed and non-delayed signals (notice the clip -1 1 operator for waveform hygiene), and to create a mixable delay line. In both cases, we’ve added a param operator that allows us to send messages to the gen~ object to set values by means of messages to our gen~ object. Of course, we could have adding another in operator or two and used the MSP sig~ object to control our patch - you might find that technique more to your liking, in fact.

The wet-dry mix should be pretty straight ahead, but I want to take a minute to consider this generalized example of using the mix operator for feedback and data smoothing. Here's a generalized example of how to add feedback effects:

The feedback portion of the patch also uses the mix operator along with a param operator to control the balance of the current and previous signal values. Since the Gen environment is synchronous, we can’t connect the output of the mix operator directly to one of its inputs to create a feedback loop. But don’t worry – the Gen history fb 0. operator functions as a single-sample delay line and will allow us to add the mixed signal back to itself (typing an argument into the history operator also lets us specify a starting value of zero for our feedback loop). If you have a specific kind of data smoothing in mind that doesn't require modication of the amount of the previous signal being mixed in, you can add an argument to the mix object (e.g. mix 0.5) and skip the param object entirely. The clever trainspotter reading this tutorial is probably already thinking, "Hmm. Isn't that a kind of lowpass filter?"

Yes, it is. And if you spend some quality time in the Gen examples folder, you'll see some variation of it used quite often.

In the case of our example patch, we're using this feedback loop twice in the patch - once for the left and right channels. In the case of our example patch, we send the averaged sample values on as output to the wet/dry mix, and also re-inject them into our delay operator. The result is the classic ringing delay line with a damping control. You can use this particular kind of patch for all kinds of useful tasks.

Note: the fold -1 1 operator makes sure that the feedback values never increase above a value of 1.0 or below a value of -1.0 – if they do, they’ll be folded back for the next iteration. It’s a simple way of producing self-regulated output.

Try the patch with a variety of different kinds of input audio files – some things will sound interesting, some won’t (that’s because an algorithm is never an automatic guarantee of interesting output unless you’re a hard-core formalist).

Doubling Down

Often, you don’t really need to do anything really difficult to get good results. Our second patch drive-by1b.maxpat builds on that with a few simple extensions. Since one damped ringing delay line sounded pretty wonderful, let’s add another one for each channel (and an MSP line~ object in the patch to smooth things out a little on input), and let’s also add another of those mixer-history-feedback modules to the overall output to add some ringing to the combined signals. I’ll wager that the resulting howling and humming will get you thinking about the same thing as I did – I started using mathematically related input values for the number of samples to delay to get tuned or harmonic effects. Please feel free to live with the harshly soothing sound of this patch for a while.

Pitching Practice

drive-by1c.maxpat, the third iteration of our patch, does its work outside of the gen~ object itself – it adds a simple little subpatcher named that lets us tune the ringing delay lines by using a keyboard – I’m sure it’s occurred to you that this would be handy to do (although I found tuning the delay lines by hand to be a pleasant and restful activity). Here’s the inside of the subpatcher for your study and edification.

I’m sure that some of you may already be thinking about just intervals (musical intervals that can be expressed as simple whole-number frequency ratios) rather than living with the equally tempered intervals that the Max mtof object produces. Feel free to make those changes for yourself (they sound pretty wonderful, trust me).

It's the Network, Silly....

drive-by1d.maxpat, the fourth iteration of our drive-by tutorial patch, adds a final minor variation that manages a modestly impressive major transformation of the proceedings.

All we've added is a gate operator, which functions in much the same way as its Max and MSP cousins - an incoming message relayed by way of the param operator named feeder is used to send the delayed signal for reinjection into the delay line to one of the four delay lines we've set up. That means you can route your signal back to itself (as we've done all along), to the second tuned delay line on the same audio channel, or to the first or second delay lines on the opposite channel. The result of this reassignment is that the ringing delays become quite complex - the interplay of damping and pitch and the routing of the delayed signals result in some really interesting sounds.

Of course, there are always other possibilities. More ringing delay lines? Sure. More complex routing? You betcha. More subtle approaches to amplitude control? Why not? This is a shameless attempt (as is the omission of the wet/dry mixer logic in the last couple of examples, to be honest) to encourage you to play around with the patch. Good luck and happy patching!