Back in 2007 and 2008, I put together a system in Ruby which emulated a hardware drum machine, but changed one piece of the classic design: where most drum machines map beats to drums using booleans, this used floats. The floats expressed probability. Since then Arturia, Elektron, and other companies have released drum machines which allow you to do similar things, although they default every probability to 1.0, and you need to do some menu-diving in order to change that.

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.