The BBox Drum Generator is an Arduino-based Midi sequencer mounted inside a Banana Box. The BBox contains a few preset drumbeats. These drumbeats form the basis for a drum variation algorithm (explained here). The amount of introduced variations is controlled by the blue rotary knob.
I've created four pushbuttons by mounting LEDs on top of PCB mounted mini pushbuttons. This idea is based on this article.
The two top buttons navigate through the functions of the BBox. The two lower buttons change the value of the function. Currently only the BPM and the Drum Preset can be changed.
The BBox only generates midi messages, the sound is generated by a Roland Juno-D.
The context I've been experimenting a bit with the Arduino as a basic midi sequencer. A drum sequencer is a good place to start. It's easier than an actual melodic music sequencer. You can leave out the length of a note, as a drum is a one-shot sounds device.
Because allowing the user to program drum sequences himself requires an extensive interface, or a piece of software, I thought I would write a drum generator.
Wouldn't it be cool if you can just push a button and a computer/chip does the whole creative process for you?
Yes, it would. But it scares me a little bit as well.
I've started with a mechanism that chopped up existing drum sequences in pieces and reassembles them to generate new drum sequences. This could work for breakbeat style drum patterns, but most of the time it seemed to create a build up of expectations, only to leave the listener behind with an empty feeling.
The drum sequence format Because the format in which the drum sequence is saved on the Arduino is essential to the Drum Variation Algorithm, I will explain this first.
The size of the RAM memory of the Arduino (based on an Atmega168) is small. Really small. Only 1kB. 1024 bytes. 8192 ones and zeros.
I'll just pause here for a while to let this sink in, I suggest you do the same.
Alright, if I want to use lots of data structures, I will have to make them small. The best way to make data small, is to assume as much as you can about the data in question and limit the possibilities as much as possible. So I introduced three limitations.
The drum pattern has a maximal resolution of 16th notes
For one instrument, the maximal number of notes that can be played in one measure is 16
There are only four velocity levels
Midi allows 128 velocity levels, I've made a mapping from 0, 1, 2, 3 to 0, 40, 90, 110 respectively (off, soft, medium, hard)
A measure consists of a maximum of three instruments
A typical measure consists of a hi-hat, a snare and a bassdrum, but which instruments are used is configurable
So if a measure has sixteen notes with four velocity levels, one measure for one instrument can be encoded in 4 bytes.
This is a typical drum notation which is used a lot online. I've used large and small X's to indicate the velocity level.
In the datastructure I've described above, this would look something like this. (A B in front of ones and zeros is the binary representation of a number: 11 = B1011 = 0xB)
The first number defines the instrument as a midi note number. 42 is a hihat, 40 a snare drum and 36 a bass drum. The total amount of bytes needed to encode a measure of 3 instruments with a maximal resolution of 16th notes requires ... 15 bytes.
A clearer representation would be a number in base 4, but afaik this is not possible in C/C++. B11001000 would be 3020, so a hard hit on the first 16th note, nothing on the second, a medium hit on the third and nothing on the fourth.
The Drum Variation Algorithm
If you've gotten this far, the algorithm itself is actually really simple, I hope it is not too much of a let down. If it is, I will gladly remind you of Occam's Razor.
Everytime a new measure starts, each byte of the datastructure (except the instrument note numbers) is bitwise XOR'ed with a random byte (a number between 0 and 256). The actual random number being calculated is one between 0 and a variable limit [controlled by a potmeter]. If the number is greater than 255, the original byte is left alone. With this you can control the amount of introduced variations.
Why bitwise XOR? It seems good at keeping the feel of the original pattern. It introduces new notes, but an XOR is also affected by the original byte. A bitwise OR can only add notes and a bitwise AND can only take them away.
Here is a video demonstrating the algorithm, the knob controls the amount of introduced variations (it also demonstrates the BBox Drum Generator, a post about this will be here soon).
"Wait, what? And you are writing a post about that?"
Ok ok, not very spectacular. I agree. But I replaced the broken red LED with a blue one! Still not excited? Ok, you may leave.
For the rest of you, here is a picture.
For those that are interested: the scroll wheel works with an infrared emitter and receiver. The infrared light is blocked and unblocked for every scroll "click". I did not know this, so I thought I'd share it with you. To be honest, I never really gave it any thought..
For people that like salvaging parts, here is a list of parts you can probably salvage from a broken optical mouse:
Several pushbuttons
A tiny camera with crappy resolution
Infrared receiver and emitter
An LED.. :)
USB cable [with one half missing]
Some chips, but I'm not sure if they will be helpful, or if you will be able to find datasheets
Mind you, it's a broken mouse. So some parts may not work :D
