Here’s the basic design I came up with.

These dimensions weren’t exact. This was just a way to flesh out the UI controls. But I wanted to get specific about the controls so I could figure out what parts to buy from SparkFun.

These are the parts I had in mind: a pushbutton rotary encoder with built-in RGB LEDs, a transparent plastic cap, a membrane potentiometer (a touch strip), and a 14-segment display.

But my design has 17 encoders, and at over $20 apiece (if you count the caps), that’s well over $300, just for an experiment. Also, although I’ve built some stuff from kits — including a Moog Subharmonicon — I still don’t really know what I’m doing. Finally, SparkFun didn’t have the touch strip I wanted in stock, but they did have a shorter one. So I came up with a simpler design that will still allow me to build a 4-drum, 16-beat Arx, but which has fewer moving parts.

Here’s the new, simpler design:

This design still uses the display, and the encoder beside it, for a menu-driven interface, and it still uses the touch strip to override the probability generation and provide values manually. This allows you to switch between a generative approach and a more hands-on, layer-oriented approach, as I explained in the previous post. Long story short, the display, its encoder, and the touch strip all still function as in the original design.

The main thing which changed is the purpose of the top row of knobs. In most drum machine designs, that usually represents the number of beats. For instance, consider this basic drum pattern:

You might implement that by having each knob in the top row represent a beat:

Then you’d use the encoder next to the display to choose between the drums. In this type of UI, the row of buttons represents a row in the drum grid above. This is how most drum machines work. But if I did it that way, I’d only get a 4-step sequencer out of it. Each individual button would represent a column, which is to say a beat, and there’s only four of them. That’s pretty much only fit for polka, military marches, and extremely simplistic examples in blog posts. To make the kind of music I want to make, I want a 16-step sequencer at least. But if I’m starting with just 4 encoders (or really 5), then I can’t use a design which maps beats to encoders, one for one.

But you can also have each button represent an individual drum, and have the row of buttons map to a column in the drum grid. That’s what I plan to do. I’ll have each top row knob represent a drum, and let the user scroll through the beats using the display and its knob. So if your first beat has a kick drum (knob 1) and a closed hi-hat, per the grid diagram above, that first column in the grid might map to the row of encoders like this:

And each beat maps its column to the encoders in the same way. So when you use the knob next to the display to scroll to the next beat, which has a kick, a clap, and an open hat, you see this:

And, as in the previous post, the intensity of the LED would reflect the probability of the drum playing on that beat.

This UI would probably be a little less obvious at first, with a marginally steeper learning curve, but it would look a lot cooler when playing the beat, since it could scroll through the steps as it played. In practice, that would mean a lot of flashing lights. And there’s no reason a drum sequencer built this way couldn’t have 16 steps, or 32, or 64.

Big caveat: since I have no idea how to build a case for this, and this is my first time designing and building my own hardware, it’s probably going to look like a lot more chaotic than these mockups. Still, I think this is a good compromise design.

I can’t criticize menu-diving too harshly, as my own system required me to edit raw code, live, while it sent MIDI into Reason. Here’s a demo:

However, I do think 1.0 is an overly cautious default for drum probability. And although my system is now unnecessary if you want to pit a random number against a mesh of probabilities, it had another, simpler feature which allowed you to use the probability mesh in a simpler and more dramatic way. You could also just set the “probability” by hand.

Say that you have a random number generator, it generates numbers between 0 and 1, and the rule for your probabilistic drum system is that the drum will only make a sound on any given beat if the random number for the drum, on that beat, is less than or equal to the drum probability.

Say also that you’ve got this probability mesh generating your drum patterns:

You could use this mesh in a couple different ways:

• You could say “generate a new random number for each beat, and each drum, and compare that to the probability value for the beat and the drum.”
• You could say “generate a new random number for each measure, and compare that to the probability value for each drum and beat.”
• You could say “allow the user to simply choose a number, and compare that to the probability value for each beat/drum pair.”

The first two options are subtly different. Generating a random number on a per-measure basis puts the focus on layers; generating it on a per-drum and/or per-beat basis creates breaks and fills. When it comes to the probabilistic drum machines that are on the market today, I don’t know which approach they use, and to find out, I’d have to do some real digging through manuals (and possibly forums). My system used both.

My system is also the only system I know of which gives you the third option. If you allow the user to specify the number themselves, you get a very layer-centric approach. It’s pretty much inevitable that the user will discover they get sparse beats at one end of the spectrum and dense beats at the other. The obvious next step is to transition through that spectrum, making the beats sparser or denser, depending on what the rest of the music needs.

I called my system Archaeopteryx. It’s a very obscure joke: the archaeopteryx was a transitional species, either the last dinosaur or the first bird. Is an instrument which improvises its own breakbeats the last dinosaur or the first bird? The last instance of primitive humans making music by hand, or the first instance of sophisticated AIs making music for us? But I got tired of the joke, especially since most people didn’t get it, because they didn’t recognize the name of this species off the top of their heads. This was my favorite dinosaur when I was a child, and it never occurred to me that other people might know it by name. But they didn’t. What they did notice, instead, was that the name was hard to say. So let’s call it Arx instead.

Arx was powerful and useful, but the UI was not user-friendly. I sometimes got confused by it, and I was the one who wrote the code. Other people found it completely baffling. I showed a lot of people what it could do, mostly at various Ruby conferences, and they were often impressed — but they couldn’t often use it.

So I’ve been thinking about a hardware user interface.

Here’s what it might look like:

This is a simple, long box with two rows of controls. The first row has 16 pushbutton rotary encoders with LEDs inside. The second row has another of these encoders next to a display, plus a long ribbon controller underneath the row of encoders.

If you were defining a beat, you first might use the bottom encoder to choose a drum using the display, and then push the buttons on the quarter notes to set up a standard four-on-the-floor beat for the kick:

The idea here is that pushing the buttons would set your drum probability to 1.0. But you could also use the rotary encoder to set the probability to some number between 0 and 1. If you did, the instrument might use the LEDs in the encoder to show the same basic color, but at a lesser intensity or in a different hue, and thereby display that number like this:

You could use the same user interface operations to define a hi-hat pattern — or really, a hi-hat pattern generator — with a lot more variation in it than the kick had.

Then you could use the display and its encoder — a little menu system — to select any of the three “randomness” types above:

• You could say “generate a new random number for each beat, and each drum, and compare that to the probability value for the beat and the drum.”
• You could say “generate a new random number for each measure, and compare that to the probability value for each drum and beat.”
• You could say “allow the user to simply choose a number, and compare that to the probability value for each beat/drum pair.”

And if it’s the third type of “randomness,” which is not actually random at all, you could have the user choose the number by sliding their finger along the ribbon controller.

This means that after you program in your basic beat, you get an enormous range of variations, breaks, fills, and layers that you can explore with your hands, in real time, while the music plays.

This hardware UI for Arx would give you the same flexibility and power as the original system, but it would be much easier to use. To put it another way, using it would be a much more intuitive and musical experience.

I came up with this idea back in 2014. I wanted to reconcile two competing aspects of the typical live electronic music experience. On the one hand, I know (like any promoter) that it’s headliners who sell tickets. But on the other hand, I wanted a new way to understand live performance which would counteract the concept of the superstar DJ and focus instead on communal experience.

There’s inherent tension to these two forces. When superstar DJs make any kind of sense, it’s because better musicianship results in better music. On the other hand, a musical experience where dancers interact with each other is very different, on an emotional and spiritual level, from one where everybody stares at the superstar.

And, while big stadium DJs often just play their own music, there’s another school of thought around DJing which treats reading the crowd, and letting that reading guide your track selection, as an essential part of the experience. In this model, a DJ doesn’t just perform, they also sort of facilitate collaboration. To be fair to the stadium DJ, however, it’s a lot easier to read a crowd when that crowd is not unimaginably large and stretching so far into the distance that you cannot possibly see everyone’s face. So another way to look at it is to say there’s a spectrum, from a party to a show.

Either way, I wanted to reconcile these two somewhat oppositional tensions, and I also had a simpler goal: to find a way to use modern technology to make live electronic music performance more exciting than watching some dude poke at his laptop, without moving too far down towards the show end of the party/show spectrum.

My idea was to leverage user-generated visuals and software-enabled audience participation.

By user-generated visuals, I mean that in addition to using the MIDI signals from an electronic drum pad or drum kit to create music, you can also use those same signals to drive visualization software as well or instead. I built some software in Clojure along these lines. The code is on GitHub.

Here’s a quick video demo I recorded back in 2014.

Anyway, what I envisioned was a raised drum platform at the center of the venue, with video screens and concert lighting attached. The video screens would plug into software which accepted MIDI input from the electronic drums, so that the musician could also function as a VJ, or in collaboration with a VJ (who could choose to process the MIDI input through any visualization software which accepted MIDI).

There’s a fun irony here: putting the performer in the center of the venue de-centers them in terms of the experience. It pulls the experience closer to the party end of the party/show spectrum. Because if you’re behind the performer, and they have their back to you, but you’re surrounded by dancers, you might just turn around and interact with the dancers instead.

Anyway, throughout the room, you would also have a drum circle of MIDI-enabled drums, which would not necessarily create any sound, but which would drive visualizations on screens nearby. Sound would be optional; vision would be the key. These drums would go on smaller raised platforms, probably enclosed in “audience participation pods” for security, and to simplify managing them during the event.

That could work a lot of different ways. Maybe audience members buy tickets, or take turns. Maybe it’s not audience members in the pods, but percussionists; you could use this system to distribute a band throughout a venue in a way that could never have happened without modern technology, or you can use it blur the boundaries of audience and performer, creating a new intermediary group which is a little bit of both.

The visualization software which the pods control could be as goal-oriented and structured as music games like Guitar Hero, Rocksmith, and Beat Saber, but what I envision here (and even built a prototype of, per the above video) is more freeform, artistic material designed to encourage creativity and spontaneity. Likewise, these pods could send the MIDI that they capture from the audience to the main performer, or to a VJ working with the main performer, who could process it in real time. Capturing audience movement data in this way, and integrating it with the performance visuals, makes this more of a communal experience to share, and less of a staged spectacle to consume.

Either way, with the hardware all in one place, it’s easier to manage. It’s also easier to distribute the pods throughout the venue. They could be very close to the main performer, or quite far. You could have four of them, as in these rough sketches, or forty, or four hundred. (Also, the main performer wouldn’t need to be a drummer, necessarily. They could be a DJ, or a band.)

Dispersing these drum pods throughout the venue means that the crowd gets several additional areas of local focus. If this were a concert design, the new areas of focus might just host video displays, showing you the main performer and reinforcing their centrality. Instead, it de-centers the main performer.

The drum pod plays a more local role, creating visuals which may communicate back to the main performer but which definitely display in front of the nearby audience members. And the drum pod is optional. In a stadium crowd where thousands of other people are staring at a performer, you’re going to turn your head in the same direction. If you’re in the middle between the main performer and the audience participation pod, you can turn your attention to either of those focal points, or to the people around you.

This design can restore party factors to shows, and give you some control and self-determination in positioning your event on the party/show spectrum. If you want a big party with a performer in the middle who most people don’t even realize is there, you set up a lot of audience participation pods, and you make the central “stage” pretty modest. If you just want to sprinkle some magic party dust on top of a big show, you keep a big, stadium-style stage, but you add a few drum pods here and there, and you staff them with trained professionals instead of opening them up to audience members. To crank the hippie factor up to 11, have the drum pods contribute not just visualization MIDI but audio from the drums as well. To present a flawless, rehearsed performance, restrict the drum pods to visualization only, and have a VJ or team of VJs carefully curate any visualization MIDI which the drum pods contribute.

Any given event will have its own preferred blend of party factors and show factors. Big music festivals today often crank both factors up to 11. This system is a framework that can work well in multiple different contexts.

Here’s the beat again:

And here’s the riser:

Next, here’s the code:

// riser
SynthDef("riser",
  { arg amp = 1, startPan = -1, endPan = 1;
    // envs
    var env1 = Env.pairs([[0, 0], [0.4, amp], [3.1, 0.5], [3.5, 0]], \lin); // amp env
    var env2 = Env.pairs([[0, 55], [0.4, 110], [1, 220], [3.1, 1760]], \lin);
    var env3 = Env.pairs([[0, 50], [4, 1]], \exponential);

    // build oscs on the envs
    var squiggly = Saw.ar(freq: SinOsc.ar(env3.kr(doneAction: 2)).range(30, 19900),
      mul: (env1.kr * 0.6)) * amp;
    var riser = Saw.ar(freq: env2.kr, mul: (env1.kr(doneAction: 2) * 0.8)) * amp;

    // first combine these mono channels in a stereo space, then add reverb
    var combined = Pan2.ar(squiggly + riser, pos: Line.kr(startPan, endPan, 4));
    Out.ar(0, FreeVerb.ar(in: combined, mix: 0.5, room: 0.5));
}).add;

As usual, starting off with SynthDef("riser", {...}).add; creates a callback function and registers it under the name “riser.” The callback function takes three keyword arguments — amp, startPan, and endPan — and amp plays its usual role in defining the amplitude, or volume, of the function. Likewise, startPan and endPan play the same roles they play in the synth hat code in the previous post.

In the previous two posts, we’ve seen Env.perc, a tight, quick envelope well-suited to drum synthesis. The Env object has many other methods, each of which generate different types of envelopes, like Env.adsr, Env.dadsr, and Env.asr. This code uses Env.pairs, which is the most flexible option. Env.pairs takes an array of two-element arrays. These pairs each represent the time and level of a point in the envelope. The envelope can have any number of points, and you can also pass in a symbol or string to specify the type of curve you want the envelope to have.

With that in mind, let’s look at the envelope code.

// envs
var env1 = Env.pairs([[0, 0], [0.4, amp], [3.1, 0.5], [3.5, 0]], \lin); // amp env
var env2 = Env.pairs([[0, 55], [0.4, 110], [1, 220], [3.1, 1760]], \lin);
var env3 = Env.pairs([[0, 50], [4, 1]], \exponential);

Two of the envelopes use a linear curve; the third is exponential. The first one lasts three and a half seconds, the second one lasts a little over three seconds, and the third lasts for four seconds. The first envelope starts with a level of zero, goes up, and then goes back down to zero again. The third envelope likewise ramps down from fifty to one. The second one is the exception; it starts at 55 and ramps up to 1760.

As you might guess, env2 is a pitch envelope. A common technique with risers in dance music is to build up from a low frequency to a high one, and that’s what happens here. If you’ve been following along with the previous posts, you won’t be surprised to learn that the top frequency of 1760 represents a high octave of the note A, and the bottom frequency of 55 repesents a low octave of A. Here’s the code which uses this envelope to create a sound running through these frequencies.

var riser = Saw.ar(freq: env2.kr, mul: (env1.kr(doneAction: 2) * 0.8)) * amp;

This is one half of the riser sound. To make it easier to understand, I took out the other half for this recording:

That rise in pitch is what the code is doing right now.

Saw is a SuperCollider unit generator or UGen, an object in SuperCollider which generates sound. In this case, it generates a sawtooth wave, a classic element of subtractive synthesis since the 1960s. By invoking its .ar method, we modulate it at audio rate. So first we pass in the frequency we want with freq: env2.kr, which simply means we’re going to take the control output of the pitch envelope which runs from 55 to 1760, and supply those values to freq over time. Then we pass env1.kr as the value for the Saw UGen’s mul keyword argument. This means we’ll use env1 as an amp envelope. A doneAction of 2 is equal to the value of Done.freeself, and means that SuperCollider will free up the Saw UGen’s memory once it’s done playing this sound. The code multiplies the amp envelope by 0.8 to tone the volume down a bit, and the whole thing gets multiplied by amp, which allows us to make further volume modifications elsewhere in the code, if we need that. If we don’t, multiplying by amp does no harm, since its default value is 1.

Now, as I said, I took out half of the riser sound so that we could understand that part. That part, named riser in the code, does an actual rise in pitch. The next part adds texture. Here’s what that other half sounds like.

And here’s the code.

var squiggly = Saw.ar(freq: SinOsc.ar(env3.kr(doneAction: 2)).range(30, 19900),
  mul: (env1.kr * 0.6)) * amp;

As before, we’re just passing freq and mul to a Saw sawtooth wave UGen, but the results are very different. Or actually, the results with mul are virtually the same; the only differences are that we make the UGen quieter, by damping it down by a factor of 0.6 instead of 0.8, and we don’t dispose of it with doneAction: 2. The reason for that is the code we pass to freq needs the Saw.ar to stick around until env3 is done, and env3 lasts four seconds, while env1 (the amp envelope controlling mul) lasts 3.5 seconds. We could shorten env3 to 3.5 seconds as well if we needed to, but in practice, it doesn’t cause any problems.

Anyway, the mul is clear. What’s going on inside freq is a little more unusual:

Saw.ar(freq: SinOsc.ar(env3.kr(doneAction: 2)).range(30, 19900)

In the same way that calling Saw.ar gets SuperCollider to give us the audio output of a sawtooth wave generator, SinOsc.ar gets us the audio output of a sine wave generator. Passing only one argument to SinOsc.ar means we’re just defining the frequency of the sine wave, and that frequency is a slow envelope that, over 4 seconds, starts at 50 and goes down to 1. However, we then call range(30, 19900). This is actually a method on UGen itself, the superclass, which scales the output of the UGen to fit within the range of frequencies defined. So our sine wave actually starts at 19.9 kHz and scales down to 30 Hz, which is almost the lowest frequency a human being can hear. But wait! Will any ear ever hear this frequency? Because we’re not feeding it into any audio output; we’re simply using it to generate the freq argument for our Saw. What’s going on here?

We’re using our SinOsc as an LFO. At the start of its frequency envelope, it’s oscillating at 19.9 kHz, which is way too fast to really qualify as an LFO — it stands for low-frequency oscillator, after all — and instead basically performs FM synthesis, modulating the sawtooth wave very quickly. As it slows over the course of four seconds, however, it enters LFO territory. So you get a transition in texture over those four seconds. I wish I could say I thought of this myself, but it’s an idea I stole from a Microkorg preset. The Microkorg version didn’t go into FM territory, but the idea was the same.

There are a few more lines of code which add just a little special sauce to this sound.

// first combine these mono channels in a stereo space, then add reverb
var combined = Pan2.ar(squiggly + riser, pos: Line.kr(startPan, endPan, 4));
Out.ar(0, FreeVerb.ar(in: combined, mix: 0.5, room: 0.5));

Pan2.ar turns mono sounds into stereo sounds, and the pos argument (for “position,” i.e., pan position) is the control rate information from a Line drawn, over four seconds, from startPan to endPan. Those values are -1 and 1, respectively, which in this context stand for a signal panned all the way to the left and a signal panned all the way to the right. In other words, we make the sound move across the stereo spectrum. Meanwhile, FreeVerb adds some reverb to the sound, just to give it a bit of presence.

And that’s how we get the end result.

First, here’s the track:

This is kind of just a demo, and a real house track would be maybe twice as long, but I think it serves well as a proof of concept. If you’ve been following the previous posts, you recognize these drum sounds, as well as the riser. The previous posts explain those sounds in detail. What’s new are some more melodic sounds — a synth pad and a sound like low bells or perhaps piano strings being scraped — and the fact that this is a track rather than an eight-bar loop.

So there are just three things to explain:

• pattern sequencing in SuperCollider
• the pad synth
• the bells / piano strings synth, which uses Karplus-Strong synthesis

We’ll start at the beginning. As before, there’s a git repo on GitHub, and you’ll need to run a simple installer script if you’re following along in SuperCollider. The git repo has a README which explains how to do that.

Pattern Sequencing in SuperCollider

In previous posts, we saw that SuperCollider provides a mechanism for sequencing called Pbind, for pattern binding. Pbinds allow us to play musical patterns like drumbeats and melodies. The question is how to sequence them, one after the other.

SuperCollider has a mechanism for this called Pspawner. You invoke Pspawner along with a callback which takes a spawner object as an argument. It’s idiomatic for this object to be named spawner, but in this code, I went with the name salmon since I was in a goofy mood and spawning is a thing that salmon do.

Here’s how a typical use of Pspawner might look:

~synthHatPattern = Pbind(
  \instrument, \hat,
  \dur, 1/4,
  \amp, Pseq(~hatAmps, inf),
  \startPan, Pseq(~hatStarts, inf),
  \endPan, Pseq(~hatEnds, inf),
  \pitchVariation, Prand([3520, 2637, 7040], inf),
  \release, Pseq(~hatReleases, inf)
);

~clock = TempoClock(125/60);

Pspawner({ arg salmon;
  salmon.par(~synthHatPattern);
}).play(~clock);

The spawner’s .par method stands for “parallel,” and it sets a pattern playing which can play in parallel (i.e., at the same time) with other patterns. We’ve seen this Pbind code in previous posts. All in all, this code will give you results which are basically identical to calling .play(~clock) at the end of the Pbind. But because we’re using .par, we can play other Pbind objects at the same time.

Also, just like “where there’s smoke, there’s fire,” where there’s parallel, there’s sequential. The spawner has a .seq object which will play a pattern, and then, when that pattern ends, the spawner will also stop playing any patterns which it was playing in parallel. That’s what’s going on in this code, which plays the first few bars of the track:

Pspawner({ arg salmon;
  salmon.par(~crashPattern.value(2));
  salmon.par(~synthHatPattern);
  salmon.par(~stringsPad.value(2));
  salmon.seq(~kickPattern.value(6));

  salmon.seq(~riserPattern.value(1));
}).play(~clock);

This code plays a crash pattern twice, and keeps playing the synth hat pattern and a synth pad until it’s played a kick pattern 6 times, at which point it stops and plays a riser pattern once. That’s how the track begins; more specifically, that’s the first fifteen seconds of it.

But you’ll notice that I’m not just passing patterns to the spawner in most cases here. Instead I’m calling value() on these objects and passing those values to the spawner. That’s because this code is built on the code in the previous posts which played a drum pattern on inifinite repeat. All the drum patterns in that existing code worked on the assumption that they would run forever. Rather than rewrite all that code from scratch, the easiest thing was to write functions which returned Pbind objects. Here’s what one of those functions looks like:

~crashPattern = { arg measures ;
  Pbind(
    \instrument, \crash,
    \dur, 2,
    \amp, Pseq(~crashAmps, measures / 2)
)};

Invoking these functions works as shown: functionName.value(argument). This is some of the weirdest syntax in all of SuperCollider to me personally, because I would have expected functionName(argument) instead. However, prior to this, every time I’d used SuperCollider, it’d been through systems like Overtone and Sonic Pi, which retain SuperCollider’s power but replace its weird programming language with more familiar, popular languages. This is easier in terms of writing code, but it’s also harder in terms of understanding what SuperCollider is actually doing. SuperCollider is very powerful, so it’s totally worth the effort to grapple with the syntax a little. Anyway, long story short: functions which return Pbinds.

These simple mechanisms are almost all you need in order to do pattern sequencing in SuperCollider. The code for this track uses only two other methods for its sequencing. First, there’s salmon.suspendAll;. This simply stops all running patterns. Second, there’s wait(). You pass this method a number of beats, and it’ll wait for that many beats before the song moves forward. And that’s it.

Here’s this code in action:

Pspawner({ arg salmon;
  salmon.par(~crashPattern.value(2));
  salmon.par(~synthHatPattern);
  salmon.par(~stringsPad.value(2));
  salmon.seq(~kickPattern.value(6));

  salmon.seq(~riserPattern.value(1));

  salmon.par(~crashPattern.value(2));
  salmon.par(~pluckQuasiArp);

  salmon.par(~zapPattern.value(3.5)); // because this amps array is twice as long
  salmon.seq(~kickPattern.value(7));
  wait(4);

  salmon.suspendAll;

  salmon.par(~crashPattern.value(2));
  salmon.par(~stringsPad.value(2));
  salmon.seq(~kickPattern.value(7));
  wait(4);

  salmon.par(~crashPattern.value(2));
  salmon.par(~pluckQuasiArp);
  salmon.par(~synthHatPattern);

  salmon.par(~sampleClapPattern.value(7));
  salmon.par(~sampleHatPattern.value(7));
  salmon.par(~kickPattern.value(7));
  salmon.seq(~zapPattern.value(4)); // again, double-length amps array

  salmon.par(~crashPattern.value(2));
  salmon.par(~stringsPad.value(2));
  salmon.par(~snarePattern.value(6));
  salmon.seq(~kickPattern.value(6));

  salmon.seq(~riserPattern.value(1));

  salmon.par(~crashPattern.value(2));
  salmon.par(~sampleClapPattern.value(7));
  salmon.par(~sampleHatPattern.value(7));
  salmon.seq(~kickPattern.value(7));
  wait(4);

  salmon.par(~crashPattern.value(2));
  salmon.par(~stringsPad.value(2));
  salmon.par(~snarePattern.value(7));
  salmon.par(~sampleClapPattern.value(7));
  salmon.par(~sampleHatPattern.value(7));
  salmon.seq(~zapPattern.value(4));  // function should handle this

  salmon.par(~crashPattern.value(2));
  salmon.seq(~kickPattern.value(6));

  salmon.seq(~riserPattern.value(1));

  salmon.par(~crashPattern.value(2));
  salmon.seq(~stringsPad.value(2));
  salmon.suspendAll;

  salmon.seq(~crashPattern.value(2));

}).play(~clock);

It might make for cleaner/DRYer code, and/or a track structure which is easier to understand, if I were to wrap these sections up into helper functions. But to get a track going, this is enough. If you’re curious, try reading this code while the track plays. It’s pretty easy to match up the lines of code with the parts of the track.

All that’s left to explain now is the two new sounds: the pad synth and the Karplus-Strong sound.

The Pad Synth

Here’s what the pad synth sounds like:

Both this and the next patch were created by Bruno Ruviaro, one of the two instructors at the CCRMA SuperCollider workshop that I took. This patch was introduced during class. I found the next patch coincidentally, via a Google search, although it’s not really a coincidence per se that a person teaching the workshop had also written popular patches available online.

Anyway, here’s the code:

// pad synth (from presentation today)
SynthDef("padSynth", { arg midinote, gate = 1;
  var ampEnv, freq, gen, fmod, rqmod, snd;
  ampEnv = EnvGen.ar(
    envelope: Env.adsr(3, 3, 0.8, 5, 0.5),
    gate: gate,
    doneAction: 2);

  freq = { midinote.midicps * LFNoise2.kr(1,0.01,1) }!12;
  gen = LFSaw.ar(freq: freq, mul: ampEnv);
  fmod = LFCub.kr(1/12, mul: ampEnv).range(1, MouseX.kr(2,16));
  rqmod = LFNoise2.kr(1/8, mul: ampEnv).range(0.1,1.0);
  snd = RLPF.ar(gen, freq * fmod, rqmod, ampEnv);
  Out.ar(0, Splay.ar(snd * ampEnv * 0.3));
}).add;

First we define a function, and add that function to SuperCollider’s list of synths under the name “padSynth”. The function takes a midinote and a gate. In my hardware studio, I usually either send MIDI notes or gate signals, in my Eurorack modular. But they’re just data in SuperCollider, and you can use both if you want. The gate is passed to an amplitude envelope here:

ampEnv = EnvGen.ar(
  envelope: Env.adsr(3, 3, 0.8, 5, 0.5),
  gate: gate,
  doneAction: 2);

The gate signal is very important. When the gate closes, it does the doneAction. In this case (and most cases) the doneAction is 2, which is equal to the constant Done.freeSelf, so when the gate closes, the synth gets freed. In other words, SuperCollider garbage-collects it, freeing up memory. So without gate, you can bog down your computer and produce all sorts of unpleasant glitching. (SuperCollider can also produce pleasant glitching, of course.)

Anyway, an amp envelope is a fairly standard feature in a synthesizer, but the rest of this code features some interesting quirks. Although it holds to the same basic model as a classic subtractive synth, the freq in this synth isn’t just determined by converting the MIDI note into a frequency. It also multiplies that frequency by the output of a noise generator, to produce a wavering and not quite perfectly tuned sound, reminiscent of classic 1970s/80s analog polysynths:

freq = { midinote.midicps * LFNoise2.kr(1,0.01,1) }!12;

The !12 means “create twelve copies of this.” This thickens the sound.

The next few lines control the filter.

fmod = LFCub.kr(1/12, mul: ampEnv).range(1, MouseX.kr(2,16));
rqmod = LFNoise2.kr(1/8, mul: ampEnv).range(0.1,1.0);
snd = RLPF.ar(gen, freq * fmod, rqmod, ampEnv);

With rqmod, it uses a noise generator to modulate the filter resonance, and it puts an LFO on the filter frequency with LFCub, which I believe stands for “low-frequency cubic,” because it outputs a waveform similar to a sine wave but made of cubic pieces. The top frequency is determined by the mouse position, which I actually forgot when I was recording the audio samples in this blog post, but if you clone the repo and run the installer, you can experience this effect by moving your mouse while the pad sound plays. The function then feeds these generators into RLPF, which stands for “resonant low-pass filter.” As explained in a previous post, Out and Splay just send the audio to an output bus and pan it across the stereo image, respectively.

So that’s how the pad works. Let’s look at the Karplus-Strong sound.

Karplus-Strong Synthesis

The creators of Karplus-Strong synthesis, Kevin Karplus and Alexander Strong, originally called it “digitar” synthesis, because they felt it produced digital guitar hybrid sounds. It’s easy to understand where they’re coming from. Here’s the Karplus-Strong or digitar sound from the track:

Here’s the code:

// Bruno's Karplus-Strong synth
SynthDef("plucking", {arg amp = 0.1, freq = 440, decay = 5, dampen = 0.1;

var env, snd;
env = Env.linen(0, decay, 0).kr(doneAction: 2);
snd = FreeVerb.ar(Pluck.ar(
        in: WhiteNoise.ar(amp),
        trig: Impulse.kr(0),
        maxdelaytime: 0.1,
        delaytime: freq.reciprocal,
        decaytime: decay,
    coef: dampen,
    mul: env
  ), mix: 0.7, room: 0.8);
    Out.ar(0, [snd, snd] * env);
}).add;

I didn’t write this code, but I can tell you roughly how it works. The Pluck is a Karplus-Strong unit generator; you set its delaytime at the reciprocal of the frequency you want to hear because Karplus-Strong synthesis works by looping a short burst of noise through a delay which is also set to a quite short time. In a situation like that, the pitch of the resulting sound — which is ultimately just white noise echoing a lot — is inversely proportional to the delay time. That’s because the looping of the delay functions like an oscillator, generating a waveform by looping the initial burst of white noise. In a sense, Karplus-Strong is a relatively simple form of wavetable synthesis. Anyway, returning to the code, the WhiteNoise provides the noise, of course, and the Impulse makes it a short burst. The amp envelope generated by Env.linen is not staccato, but that’s applied to the overall sound.

So this is how you construct a complete track in SuperCollider. This is the capstone of the past few blog posts, which are so far the only ones on this blog, so I hope you’ve found this edifying, inspiring, or at least useful. You can make complete tracks entirely within SuperCollider, and hopefully these blog posts have shown you how.

First off, here’s what the beat sounds like:

There are five types of sound in this beat:

• Sample playback (the clap, the open hi-hat)
• Simple drum synthesis (the crash, the closed hat, etc.)
• Complex drum synthesis (the ride)
• A bell-like synthesizer patch
• A riser

The riser is complex enough that I’m going to save it for another post. Plus it’s not a drum. The bell-like patch is something I copied from Bruno Ruviaro. I found his code for the synth on sccode.org (which currently has an invalid SSL cert, sorry), but I actually found it while taking a workshop on SuperCollider at CCRMA 2018, and Bruno was teaching this workshop (along with Fernando Lopez-Lezcano). It’s a pretty cool sound, and when it came to getting this code up and running in the workshop, Bruno was instrumental in that (sorry for the pun). But it’s not a drum either, so I’m going to skip it for now.

This leaves three drum categories:

• Sample playback (the clap, the open hi-hat)
• Simple drum synthesis (the crash, the closed hat, etc.)
• Complex drum synthesis (the rides)

I’ll explain them in that order.

Sample Playback Drums

The simplest way to make a drum sound is to take a recording of a drum sound and play it back. It’s barely even the “Hello, world” of drum synthesis. But it’s very useful, and it’s a good simple thing to explain if you’re new to SuperCollider. So let’s look at how it works.

Here’s the code which defines the sample playback “synthesizer.”

// set up clap sample
~clapBuffer = Buffer.read(s, "audio/11098__a43__a43-clap.aiff");

// set up open hat sample
~openHatBuffer = Buffer.read(s, "audio/165028__rodrigo-the-mad__mini-909ish-open-hat.wav");

// generic sample player synthdef
SynthDef("samplePlayer",{ arg out = 0, bufnum, amp;
  Out.ar( out,
    PlayBuf.ar(2, bufnum, BufRateScale.kr(bufnum), doneAction: 2) * amp;
  )
}).add;

First, the code sets up paths to its audio samples, one each in the WAV and AIFF formats. Technically these aren’t the real paths; as explained in the previous post, a simple installer script will set you up with explicit pathnames for the audio samples. After the file paths are set up, we use SynthDef to define a synth — basically an audio-generating function which you can address with a name — which takes as its arguments the index of an audio bus, the index of a buffer, and an amplitude. A buffer in this context, like in so many others with file I/O, is the in-memory storage of the data in the file. Also note that Buffer.read returns not the buffer itself, but the buffer’s index, so reading the file and keeping track of the index is all you need to use SuperCollider’s API here.

A reasonable person could at first glance think that this is a strange design decision, and maybe expect Buffer.read to return the buffer itself. Likewise, passing around the index for the output bus is a bit weird when you could just be working with the bus itself. My best guess is that you can’t just work with the bus itself, and that this weirdness, like most computer-related weirdness, is due to distributed systems. SuperCollider uses a client/server architecture, which is beyond the scope of this blog post, but which would explain why the language could only work with references to buses and buffers, and not have direct access to those buses or buffers themselves as objects.

Anyway, the most important line in our sample player is here:

PlayBuf.ar(2, bufnum, BufRateScale.kr(bufnum), doneAction: 2) * amp;

A PlayBuf is a SuperCollider object which plays an audio buffer. The .ar here, and everywhere in SuperCollider, means that we’re going to send signals out from this object at audio rate. The 2 signifies two channels, i.e., it’s a stereo sample. The bufnum is the index of the buffer object that we’ll be getting our audio information from. The next parameter we’re passing in is our rate, i.e., the speed at which we’ll be playing back the sample. We calculate this with the help of a BufRateScale object, and we get data from that object at control rate (which is what .kr always means in SuperCollider). Think of audio rate and control rate as equivalent to audio signals and control voltage in Eurorack modular synthesis.

Everything within the {} in the SynthDef is essentially a callback function that will be invoked later, like a callback function in Node.js, so obviously we’re not saying “play this PlayBuf now.” We’re setting up "samplePlayer" as the name for the “synthesizer” which will play the PlayBuf whenever we need it to, later on.

To be more specific, let’s look at when that “later on” arrives. This is the code from timing.scd and pbinds.scd which specifies when the clap and hat samples will play:

// set up when to play the clap
~clapAmps = [ 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0 ]; // 16 beats

// timing for sampled open hat
~sampledOpenHatAmps = [ 0, 0, 1, 0 ];

// sample player: clap
Pbind(
  \instrument, \samplePlayer,
  \dur, 1/4, // 16th note is one quarter of a beat!
  \bufnum, ~clapBuffer,
  \amp, Pseq(~clapAmps, inf)
).play(mainClock);

// sample player: hat
Pbind(
  \instrument, \samplePlayer,
  \dur, 1/4, // 16th note is one quarter of a beat!
  \bufnum, ~openHatBuffer,
  \amp, Pseq(~sampledOpenHatAmps * 0.65, inf)
).play(mainClock);

A Pbind in SuperCollider represents a pattern binding, which is to say a connection between a pattern to play and the sounds which will play it. A PlayBuf doesn’t take specific notes, so these Pbind objects just take arrays of amplitudes, which is to say numbers between 0 and 1 which represent loudness. In the hat pattern binding, the code multiplies the loudnessnesses by 0.65 as a way of quieting their overall volume a little.

If this conflation of triggering the sound and adjusting its volume bothers you, it’s also possible to separate them by using gates, which are similar to the gate signals used in analog sequencers, but we won’t get into that in this blog post.

You may be wondering why ~clapAmps has 16 elements, but ~sampledOpenHatAmps only has 4. The answer is that, after hand-coding all 16 elements in ~clapAmps, I noticed this was wasteful, and used a terser syntax in ~sampledOpenHatAmps. That’s it. SuperCollider will turn both arrays into infinite sequences, since they’re passed into Pseq with an inf argument, so in this case it doesn’t matter how long they are.

Subtractive Synthesis Drums

The simplest subtractive drum in this beat is the crash.

// crash
SynthDef("crash", { arg amp = 1;
  var whiteNoise = PinkNoise.ar(
    mul: Env.perc(releaseTime: 4, curve: -7).kr(doneAction: 2));
  Out.ar(0, Pan2.ar(HPF.ar(whiteNoise, freq: 7040)) * 4 * amp);
}).add;

Here’s how it sounds.

There are more sophisticated ways to make a cymbal sound, but this is a nice simple example to start with. Let’s dig into the code.

As usual, this part means “create a sound-generating callback function named ‘crash’, and add it to the in-memory synth registry”:

// crash
SynthDef("crash", {...}).add;

Now let’s expand that ellipsis.

{ arg amp = 1;
  var whiteNoise = PinkNoise.ar(
    mul: Env.perc(releaseTime: 4, curve: -7).kr(doneAction: 2));
  Out.ar(0, Pan2.ar(HPF.ar(whiteNoise, freq: 7040)) * 4 * amp);
}

Starting off, arg amp = 1; just means that the callback function takes one keyword argument, named amp, with a default value of 1. So far so good. Next we create a whiteNoise variable, which is actually generated by invoking the ar method on a PinkNoise UGen. (A UGen is a unit generator, i.e., something which makes sound.) .ar, as always in SuperCollider, means we want audio rate output, i.e., sound. We pass in just one argument, mul, which stands for “multiply.” SuperCollider will multiply the output from the PinkNoise UGen by the value of mul. As you can see, that value is a little complex:

mul: Env.perc(releaseTime: 4, curve: -7).kr(doneAction: 2))

Env.perc creates a percussive envelope, and .kr sends the output of that envelope as a control signal. I’m not sure what the release time’s units are, but it might be seconds. At any rate, this value of 4 gives us a longer release than the default of 1, and that longer release makes sense for a crash cymbal. Likewise, the -7 curve means that the release curve of this envelope is gentler than the percussive envelope’s default. The magic number 2, for doneAction, is equal to the value of Done.freeself — an important constant in SuperCollider — and means that we want the UGen to free its own memory after it plays. This is a very important bit of bookkeeping; without it, SuperCollider will not free up the UGen. In this code, you create a new synthesizer in SuperCollider’s memory every time you play this drum. If you’re not freeing up those resources once you’re done with them, you could get audio glitching and other memory problems very quickly.

Anyway, at this point we’ve created a crash cymbal sound. Now we have to play it. That’s what the next line does:

Out.ar(0, Pan2.ar(HPF.ar(whiteNoise, freq: 7040)) * 4 * amp);

As is often the case in SuperCollider, this code works by chaining library objects and invoking them at audio rate via their .ar methods. The Out object simply sends audio to an output bus. SuperCollider will set you up with one output bus by default, and its list is zero-indexed, so that’s the first argument to Out.ar. The second argument is an array of channels, and Pan2.ar simply takes one channel and splits it into an array of two channels, i.e., a stereo pair. We use amp to define when the crash will play, just like with the sample playback drums above, and we multiply the amp value by 4 to boost the volume a bit. We also wrap the whole thing in a high-pass filter, using HPF.ar, and set the frequency to 7040, which is a high octave of the note A. (All of the drum sounds in this beat are tuned to A, or notes in the A minor scale.)

The pattern playing mechanism is similar to what we’ve already looked at above for the sample playback drums. If you want to take a deeper look, the code is on GitHub. For now, let’s look instead at a very similar drum: the synth hi-hat. Above, we saw the code which plays a sampled open hi-hat. But this beat also contains a synthesized hi-hat, and the code will look very familiar.

// basic synth hat
SynthDef("hat", { arg amp = 1, startPan = -1, endPan = 1, pitchVariation = 0, release = 0.1;
  var whiteNoise = WhiteNoise.ar(mul: Env.perc(releaseTime: release, curve: -7).kr(doneAction: 2));
  Out.ar(0, Pan2.ar(BBandPass.ar(whiteNoise, freq: pitchVariation, bw: 1), pos: Line.kr(startPan, endPan, 4)) * amp);
}).add;

This is almost the same drum. The code uses a much shorter default release time of 0.1, accepts release as an argument, and accepts some other new arguments as well: startPan, endPan, and pitchVariation. Instead of always setting a high-pass filter at 7040, it instead sets a band-pass filter to whatever frequency pitchVariation represents. It also sets the pan position using a linear control rate “drawn” between its start and end points:

pos: Line.kr(startPan, endPan, 4)

One of the weirdest things about the syntax of SuperCollider’s language is that, when you use keyword arguments, the names are optional. (It’s not optimized for clarity, but for live-coding.) The “4” in the above code could also be written as dur: 4, and specifies a duration of 4 seconds for the panning.

You might be wondering where startPan, endPan, release, and pitchVariation come from. They’re here:

// set up when to play the hats
~hatAmps = [ 0.1, 0, 1, 0, 0, 0, 1, 0, 0.1, 0, 1, 0.1, 0, 0.1, 1, 0 ]; // 16 beats
~hatStarts = [ 0.5, 0, -0.5, 0, 0.7, -0.7 ]; // hat pan timing
~hatEnds = [ -0.7, 0, 0.7, 0, 0.5, -0.5 ]; // hat pan timing
~hatReleases = [
  0.1, 0.2, 0.1, 0.3, 0.2, 0.3, 0.5, 0.6,
  0.2, 0.1, 0.3, 0.3, 0.1, 0.2, 0.4, 0.2,
  0.1, 0.2, 0.2, 0.3, 0.1, 0.3, 0.3, 0.4,
  0.2, 0.1, 0.3, 0.3, 0.1, 0.2, 0.4, 0.2,
  0.1, 0.2, 0.2, 0.3, 0.1, 0.3, 0.3, 0.4,
  0.2, 0.1, 0.3, 0.3, 0.1, 0.2, 0.4, 0.2,
  0.1, 0.2, 0.3, 0.4, 0.2, 0.3, 0.1, 0.3
]; // hat release times

Pbind(
  \instrument, \hat,
  \dur, 1/4, // 16th note is one quarter of a beat!
  \amp, Pseq(~hatAmps, inf),
  \startPan, Pseq(~hatStarts, inf),
  \endPan, Pseq(~hatEnds, inf),
  \pitchVariation, Prand([3520, 2637, 7040], inf),
  \release, Pseq(~hatReleases, inf)
).play(mainClock);

The pitchVariation comes from a Prand, which returns an infinite sequence of random values selected from the [3520, 2637, 7040] array. In other words, the band-pass filter lets frequencies through at two octaves of A, plus one octave of E. The other values come from ordered infinite sequences via Pseq, which simply repeat their arrays forever. In practice, this means that the panning follows a six-step pattern where each step takes four seconds. The releases follow a 56-step pattern, and the amps follow a 16-step pattern.

This means that just the combination of the release and amp configuration needs to play for 112 beats, or 28 bars, before it repeats. However, if you factor in the 6-step sequence of 4-second panning patterns, and consider that the changes in pitch are entirely random, you have a hi-hat rhythm which is never the same thing twice. It never repeats. Instead, there’s a lot of variety and polyrhythm in these hats. Their pitch changes, their pan position changes, their release time changes, and their volume changes. It’s just a subtle variation in a background sound, but I’m pretty happy with it. Here’s what it sounds like.

That’s it for the subtractive drums in this beat, except to note that I took the kick and the snare from an excellent blog called Rumblesan. Check out those posts if you want to understand how those drums work.

Now, let’s move on to the most complex drum in the beat.

Complex Synthesis Drum

This is the ride, aka “zaps.” I explained this briefly in the previous post, but I’ll get into more detail about the synthesis here. Here’s how it sounds:

Here’s the code:

SynthDef("zaps", { arg amp = 1, modFreq = 15, carFreq = 880, modDepth = 3250;
  var car, mod, env;

  env = Env.perc(releaseTime: 0.3).kr(doneAction: 2);
  mod = Pulse.ar(freq: modFreq * [1, 1.14, 0.97, 6, 7, 8, 9, 10, 1.04, 1.2], mul: modDepth);
  car = Pulse.ar(freq: carFreq + mod * [1, 1.41, 0.99, 2.4921, 5, 6, 1.397], mul: env);
  car = Splay.ar(car);
  Out.ar(0, FreeVerb.ar(HPF.ar(car, freq: 5274), mix: 0.05, room: 0.1, damp: 0.9, mul: amp * 0.5));
}).add;

Beyond the usual amp, this synth’s callback function has three arguments we haven’t seen before: modFreq, carFreq, and modDepth. Likewise, although you probably recognize the Env.perc and HPF.ar from the subtractive examples, Splay and Pulse are new.

Let’s start with a little context. Although I think it didn’t quite happen, I originally intended to produce this sound via frequency modulation (FM) synthesis. Where subtractive synthesis works by establishing a sound and then filtering frequencies out of it, FM synthesis works instead of by taking one sound and then using another sound to modulate it. Another way to think of it, in comparison to subtractive synthesis, might be to consider it multiplicative synthesis, because when you modulate one frequency with another, you are basically multiplying the two frequencies.

As I mentioned before, I wrote this beat during a summer workshop at CCRMA, the computer music research department at Stanford. For decades, the most profitable patent to come out of Stanford was an FM synthesis patent developed at CCRMA. This patent was the foundation of the Yamaha DX7, an incredibly popular synthesizer during the 1980s. At a party near the end of the workshop, one of the CCRMA researchers played a playlist of non-stop 80s hits powered by the DX7. There was also a DX7 in the lobby. Here it is.

Anyway, in FM synthesis, you have a minimum of two frequencies. The base frequency is called the carrier, and the modulating frequency is the modulator. That’s what car and mod are in this code. Likewise, carFreq and modFreq are the frequencies of these two sounds. We produce each sound using a square wave, which is what Pulse.ar produces. That’s roughly what these two lines of code are doing:

mod = Pulse.ar(freq: modFreq * [1, 1.14, 0.97, 6, 7, 8, 9, 10, 1.04, 1.2], mul: modDepth);
car = Pulse.ar(freq: carFreq + mod * [1, 1.41, 0.99, 2.4921, 5, 6, 1.397], mul: env);

But these two lines of code aren’t just producing square waves. This is what that simpler case would look like:

mod = Pulse.ar(freq: modFreq);
car = Pulse.ar(freq: carFreq);

So we’re doing a few additional things:

• passing mul: modDepth
• passing mul: env
• combining carFreq and mod with addition
• multiplying each frequency value by an array

First, we’ve seen code like mul: env before, so let’s get that one out of the way. SuperCollider multiplies the volume of a given audio source by whatever argument you pass to mul. With mul: env, we’re passing our Env.perc to mul, so we’re applying a percussive envelope to the sound’s volume. The other use of mul is a little more exotic. In this case, we’re multiplying it by modDepth to specify how weak or strong the modulator waveform will be. The code uses 3250 because it produces a very intense modulator wave, and because 3250 is an octave of the note A. There’s no real reason to expect 3250 to produce a properly tuned sound here; frequency modulation is notoriously chaotic in its output. I just used this frequency because I’d been using it for other things, and I kept it because it worked.

Anyway, combining carFreq and mod with addition gets us a combination of sounds which I think is maybe more additive synthesis than FM. I did this in a hurry towards the end of the workshop. However, it sounded pretty good. This is kind of how SuperCollider works sometimes. You start with a cool idea, get it slightly wrong, but keep it because it sounds good. Moving on, multiplying each sound by an array means creating many slightly modified copies of the same sound. This gives us a lot of polyphony for very little effort, with the consequence that there’s a lot of different frequencies in the “zaps” sound, and it has the kind of noisy high end that a ride should have. Finally, our call to Splay just pans these many ride voices across the stereo space.

Conclusion

So there you have it: a tour of the drum sounds (and, to a lesser extent, sequencing) in a SuperCollider house beat. We saw how SuperCollider can do simple, typical subtractive drum sounds, how it can automate parameters like release, pan, and band-pass filter frequency to create patterns with a lot of organic variation, and how its algorithmic approach to sound definition can cause an attempt at FM synthesis to take an interesting detour into additive synthesis instead. It’s a quirky beast, but it offers unique expressive opportunities, and although it can be a challenge to work with, it can also be very rewarding.

The next post explains how the riser works in this beat, and there’s some more music in SuperCollider which I hope to explain after that. Stay tuned!

Getting Started

You can grab the code from GitHub here:

https://github.com/gilesbowkett/basic-beat

You’ll need to install SuperCollider to use it. Once you have it, playing the beat becomes super easy, as shown in this video:

In the video, I kick off the beat by opening a file called loader.scd. As you probably guessed, it loads other files. Here’s the code:

(
"/Users/personal/code/ccrma-2018/supercollider-2018/project/synths.scd".load;
"/Users/personal/code/ccrma-2018/supercollider-2018/project/timing.scd".load;
"/Users/personal/code/ccrma-2018/supercollider-2018/project/pbinds.scd".load;
)

Of course, you won’t see this same code when you first download or fork the project. Instead of a SuperCollider file called loader.scd, you’ll have an ERB template called loader.scd.erb:

(
"<%= this_directory %>/synths.scd".load;
"<%= this_directory %>/timing.scd".load;
"<%= this_directory %>/pbinds.scd".load;
)

To turn this template into a SuperCollider file with the name of the appropriate directory, just run the Ruby installer:

> ruby installer.rb

This runs using the Ruby standard library on any Unix-like operating system. So the good news is that it doesn’t need a Gemfile on OS X, but the bad news is it won’t run on Windows. Sorry Windows users. Pull requests welcome!

Anyway, if you’re on OS X, you’ll see that this installer took a file called loader.scd.erb and created a new file called loader.scd. There’s a synths.scd.erb template as well, which the installer used the same way. At this point, you can either open loader.scd, or, in the worst-case scenario, open loader.scd -a SuperCollider.

Common Issue: Sample Rate Mismatch

If you see an error message from SuperCollider about sample rate mismatch, you can fix it (on OS X) by opening up the Audio MIDI Setup app — a standard utility included with every Mac — and ensuring that both your input and output devices are set to the same sample rate.

Pbinds & Timing

loader.scd loads three files:

• synths.scd — SuperCollider evaluates this file to create a set of SynthDefs, which are basically functions that have the ability to create sound. Each SynthDef has a name also. The names are very useful for live-coding or testing, since for any given name, the command Synth(name) will play the synth immediately.
• pbinds.scd — this file defines Pbinds, which are pattern binding objects.
• timing.scd — this file defines beat-by-beat timing patterns for the Pbinds to use. These are simply arrays.

To understand Pbinds and timing, consider this UI from Ableton Live, which defines a drum pattern visually. (In fact, it defines the same drum pattern as the SuperCollider files.)

This is a very common UI for drum programming. Each row represents a drum sound, and each box represents a beat when that drum will play. There are four measures in the drum pattern, and each measure is broken up into 16 beats. (Or a more proper phrasing, in terms of music theory, might be to say that each measure has four beats, and each beat has four subdivisions.)

In this color-coded version of the Ableton image, you could say that the blue area represents a set of drum sounds, each of which is mapped to a set of beats in the green area.

The blue area is like SuperCollider’s pattern bindings in pbinds.scd, and the green area is like the arrays in timing.scd.

Let’s zero in on these two bars of ride cymbal rhythm:

It’s not hard to translate that into an array. The pattern repeats every 32 subdivisions, so our array will need 32 elements. The entire first bar is empty, so the first 16 elements can just be zeros. Since this drum pattern sequence only specifies if a drum is on or off, the array can just hold zeros and ones.

ride = [ 0, 0, 0, 0,
         0, 0, 0, 0,
         0, 0, 0, 0,
         0, 0, 0, 0,

         1, 0, 0, 1,
         0, 0, 1, 0,
         1, 0, 0, 1,
         1, 0, 1, 0 ]

The actual SuperCollider code in timing.scd looks only slightly different:

// ride timing
~rideAmps = [
  0, 0, 0, 0,
  0, 0, 0, 0,
  0, 0, 0, 0,
  0, 0, 0, 0,

  1, 0, 0, 1,
  0, 0, 1, 0,
  1, 0, 0, 1,
  1, 0, 1, 0
];

SuperCollider uses JavaScript-style // comments, and the ~ prefix indicates that a variable is global. Global variables are used extensively in native SuperCollider, mainly because when you’re live-coding music, you have different namespacing priorities than you would in most other types of programming.

The timing file uses the “amps” term (meaning “amplitudes,” or loudnesses) because of how pbinds.scd consumes this data:

Pbind(
  \instrument, \zaps,
  \dur, 1/4,
  \amp, Pseq(~rideAmps, inf)
).play(mainClock);

The \ plays the same role in SuperCollider syntax that the : does in Ruby and Clojure, so \instrument in SuperCollider means what :instrument would in Ruby or Clojure. This is an extended example of passing keyword arguments in the classic Smalltalk or Objective-C style, which Ruby popularized by faking it with hashes, and which Python now fully supports. If we had been writing Ruby, the above code would have looked like this:

p_bind = PatternBinding.new(
           instrument: :zaps,
           dur: 1/4,
           amp: PatternSequence.new(ride_amps, INFINITY)
         )
p_bind.play(main_clock)

In other words, the code sets up a pattern binding with the “zaps” instrument, passes it a sequence of amplitudes based on repeating our ~rideAmps array an infinite number of times, and sets a duration of one quarter note — which brings in music theory issues that are unfortunately a bit outside the scope of this blog post. The good news: in practice, you can scrape by for a very long time with the assumption that the duration should always be a quarter note. It’s not exactly true, but it’s close enough.

Instead of stressing out about that, let’s look at what this “zaps” thing is. That’s defined in synths.scd:

SynthDef("zaps", { arg amp = 1, modFreq = 15, carFreq = 880, modDepth = 3250;
  var car, mod, env;

  env = Env.perc(releaseTime: 0.3).kr(doneAction: 2);
  mod = Pulse.ar(freq: modFreq * [1, 1.14, 0.97, 6, 7, 8, 9, 10, 1.04, 1.2], mul: modDepth);
  car = Pulse.ar(freq: carFreq + mod * [1, 1.41, 0.99, 2.4921, 5, 6, 1.397], mul: env);
  car = Splay.ar(car);
  Out.ar(0, FreeVerb.ar(HPF.ar(car, freq: 5274), mix: 0.05, room: 0.1, damp: 0.9, mul: amp * 0.5));
}).add;

Everything passed in via the curly braces at the beginning is basically a function. The arg amp = 1, modFreq = 15 section sets up a list of named keyword arguments to the function, along with their default values. The name “zaps” and the .add at the end ensure that SuperCollider adds them to some kind of in-memory synth registry, which means you can audition the sound later just by evaluating the following code:

Synth("zaps")

In practice, this is very useful.

I created the “zaps” sound while attempting to copy the synthesis of ride cymbals in the classic TR-808 drum machine. I used two articles from Sound On Sound, the British audio engineering magazine, as my guides. It didn’t really work, but it still sounds cool. The two Pulse objects are supposed to function as modulator and carrier for FM synthesis. There’s also a high-pass filter and some reverb.

Here’s what the zaps instrument sounds like, playing this pattern:

To Be Continued

This seems like a decent stopping point for now. In the next post, I explain more about how the “zaps” sound works, but I start with an explanation of the simplest drum in the beat, and build towards the zap sound’s complexity from there.