The following problem is considered by Bjorklund, in connection with the operation of certain components (such as high voltage power supplies) of spallation neutron source (SNS) accelerators used in nuclear physics.

Construct a binary sequence of n bits with k one’s, such that the k one’s are distributed as evenly as possible among the zero’s. For example, if n = 16 and k = 4, the solution is [1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0]. The problem of primary interest is when k and n are relatively prime numbers, i.e., when k and n are evenly divisible only by 1.

This is an excerpt from the somewhat melodramatically titled paper, The Euclidean Algorithm Generates Traditional Musical Rhythms. In short, sequences generated by the equal spacing algorithm described resemble various traditional rhythms, or otherwise sound pretty good. Create Digital Music did a post on various musical applications of it recently, like this neat little sequencer in flash.

Being a SuperCollider chauvinist I was happy to see Fredrik Olofsson had already written a pattern class to generate these sequences. It didn’t support embedding of patterns within it (which is what I really wanted to play with) but after a quick email to the list he patched it. Thanks Fredrik.

Anyway, here is a quick demo, with code after the jump.

What follows is a very simple example an algorithmically generated piece with some constrained randomness. This isn’t meant to be a tutorial really, but should give you an idea of SC’s general character, and convince you that it’s worth the trouble to work through the documentation.

First, the synthdef code, which is executed by the language interpreter to create instructions for the server specifying a series of unit generators and their interconnections. In other words, this code defines an instrument the later pattern code will “conduct”. There could be many of these, but here we’ll be using just one. If you come from an Ableton/Reason/Softsynth/Moog Modular background you can think of these as a bit like patches, except that you can run as many copies of them as memory and CPU resources allow, and route signals between them arbitrarily. The extreme freedom of which, while cool, makes for an initially somewhat steep learning curve.

Synths created from this synthdef take as arguments an output channel to write to, buffer number (more on this in a moment), frequency (in no particular units, because I was lazy), a gate signal, and duration. Essentially all they’ll do is play the buffer back at varying rates (to get different pitches) and sweep a filter from one frequency to another over the course of each note. These points are controlled by the X and Y (left to right, top to bottom) position of the mouse on screen. The mouse button controls the resonance of the filter, which I should mention is a very nice Moog Ladder emulation available as part of the sc3-plugins package. By wiggling the mouse around I get those acid-housey sweeps to either snap up or downward or plateau over the course of each note. Line 7 takes the mono signal from the playback of the buffer and duplicates it create a stereo signal, adding a bit of random delay to each channel to simulate the movement of the sound in space by precedence effect.

Before starting, the buffer needs to have a sample loaded into it. I used a snippet from this Imogen Heap performance, because I happened to have it around. It would sound much better (or, more positively, better still) with a higher-fidelity sample.

Each buffer loaded by the server has a number, and the variable b will hold the number this sample is assigned. Now the interesting part…

This creates a Pbind object and calls it’s play method (we create a variable, syncopate, to hold it, but we didn’t have to). The words beginning with slashes are key names, which get bundled into events, which are parts of streams which… well, it’s best that you just read the Practical Guide to Patterns if you really want to understand. For the glossed explanation I’m giving here, all you really need to know is that the \instrument parameter specifies which synthdef to use and the rest are passed to the resulting synth. So here we see \bufnum is always set to reference the lone buffer we loaded, scale is passed a major scale from the convenient Scale class’ method, the octave is set to 7, and so on.

The interesting keys are the last three, which define the amplitude (loudness), scale degree (which note, which really means which frequency, which really means which buffer playback speed), and duration for which the synth should run. What sets these apart from the others is that they’re passed Pattern objects, which can return different values each time.

The amplitude is meant to be loudest at the beginning of each beat, with each subsequent note being 90% as loud (the way an echo might decay). This is pretty subtle, and on the demo run above I (unthinkingly) used some compression, so the effect is even less noticeable. Unlike the echo-style decay you can get in most DAWs, we could do things like vary the pitch of every repetition, or have more complicated dynamic (loudness) variations. The outermost pattern, Pstep, is passed two arguments: another object (Pseq) to generate the amplitude values, and a duration. Every time a duration’s worth of time goes by (here, 1/16 of a beat), the next value will be requested from the Pseq pattern. The Pseq has only one element in it’s sequence, a Pgeom, which itself generates a series of values, each of which is a multiple (0.9) of the one before, 16 times (and since we’re moving to the next value every 1/16 of a beat, that means this pattern repeats every beat). This ability to nest patterns within one another is what makes them so flexible and expressive. The Pseq’s second parameter is the number of times it should repeat it’s sequence – here, an infinite number of times.

The degree pattern is very similar – every 4 beats, we transition to the next value from the Pseq (note also that I’m arbitrarily adding 30 to all the results – this is because of my hackish frequency scaling). So we cycle through 4 notes (spelling out a very simple melody), with 4 beats to each note. While the duration pattern described below skitters around, this gives us a bit of structure.

The interesting bit here is the pattern for duration. Duration is a bit of a special case, because while it’s passed to the synths (so they “know” how long they run), it also controls how much time should elapse before the next round of synth creation. While the other two patterns are fixed, and loop through values predictably, this pattern has a random element. The first argument to PdurStutter is a duration, the second is a factor to divide that duration by. If we passed it one and sixteen, we’d get sixteen events lasting a sixteenth of a beat each. Here I’ve used a simple Pseq for the first parameter and a Pwrand for the second. The basical metrical pattern of eight beats – two of two beats and one of four ([2,2,4]) – is set by the first (Pseq) pattern. These time segments are divided by the values from the second (Pwrand) pattern, which chooses randomly from it’s first list ([1/4,1/2,1.5,1,1/3]). The second argument to Pwrand ([10, 15, 1, 1, 1/2].normalizeSum) is a list of weights – so 1/4 is 10 times more likely to be drawn than 1.5 and 20 times more likely than 1/3.

Anyway, when the Pdef starts running PdurStutter first calls the Pseq, gets a duration of 2, and then calls Pwrand and gets, lets say, one half. It would then play four half notes (thus filling the two beats) before moving on to the next element of the pattern, which would have it’s own division factor drawn from the list. Because both the 2 and 4 beat segments are divided up from the same pool of possibilities, you get regular alternation between faster and slower repetitions. Repeat ad Ad infinitum.

All that in two lines of code. Keep in mind that we could have had much more complex patterns for the pitch and amplitude, to say nothing of the possibilities for a more interesting synthdef (you can use patterns compose for every parameter of your synths, and for effects you route them through). For more pattern examples check out the aforementioned Practical Guide to Patterns.

This sample was generated from the code above, which uses Demand UGens to sequence notes/wobble rates on lines 5 and 9. Line 6 adds a bit of slew to the pitch signal, so it glissandos (slides) from note to note, faster up than down for heightened drama.

The signal path for the sound runs: initial synthesis, distortion, filtering, a simple spatialization effect and amplitude enveloping.

The tone is initially made up of a VarSaw oscillator whose width parameter (0 = downward sawtooth, 0.5 = triangle, 1 = upward sawtooth) is “wobbled” by the LFO (line 11). A pure sine wave an octave lower is added to this (line 12). The Decimator UGen distorts this signal by rounding values to an arbitrary degree of precision (i.e. 8-bit, 2-bit, 3.2-bit) as modulated by the LFO. This produces the higher-frequency content of the signal for the filter to do it’s magic on.

The result is a bit like that seething “filthy” sound that’s so popular these days. I’ll probably do a dedicated post on it later, but the trick seems to be several square wave oscillators frequency modulating one another in turn, all through a band-pass filter.

Now that everything is sufficiently noisy it’s run through a nice emulation of the Moog ladder lowpass filter on line 14.

Line 16 splits what has until now been a monophonic signal in to two channels, each of which has a separate delay on it, the values for which are LFO-modulated out of phase with one another (so when one maximally delayed, the other has no delay). This gives the sound some (subtle?) “width” when played with stereo separation, but if you were to play this on a real rig (in mono), there would be destructive and likely undesirable interference muddying up the low end. To dodge this, you could split the signal around 65Hz and only apply delays to the high end before reconstituting it.

The triggered LFO is specified on lines 7-10. Worth noting are the phase angle bounds the Phasor UGen is sweeping through: pi to 2pi – only half of a full sine wave before resetting. Playing with these bounds can produce some interesting variations on the standard wobble.

I’ve really exaggerated the distortion to highlight the character of the sound on headphones or monitors. If you were to produce a track for dance floor use, you’d want to either generate sub-bass separately, possibly raising the line synthesized with decimation an octave or two, or ease up on the distortion; as it stands, this would be kind of weak. Try commenting out line 14 (the filter) before tweaking any parameters.