Monthly Archives: February 2013

Sampler issues: Code and hardware

So while I’ve been waiting for the components for the sequencers (which are here today) I’ve been thinking about all the lovely code I’ll get to write for the sampler.

And I’m not really loving it: Embedded programming means C or C++, and to me that’s like having the choice between the plague and cholera. Most of my previous programming endeavours have been in either Scheme or Lua, in a predominantly functional style. I know my way around both C and C++ well enough to probably do it, but it won’t be very enjoyable for me. I’ve recently read K&R and gone through some of the exercises to get back up to speed on some of the things that were a little hazy, and it’s just reaffirmed my impression: imperative programming is like talking to a particularly retarded child. On top of this, C has some warts that don’t sit very well with me: unbounded arrays, anaemic enums, and the blurry mess that is the pointer/array ‘distinction’ (or lack thereof), in addition to the lack of support for anonymous functions, closures, and tail-call optimization that I’m used to. The explicit memory management is probably more suited to resource restricted applications with rather strict timing demands, such as embedded systems which generate sound, than a garbage collected language, but at least in Scheme there should be ways around this.

There are two projects that I’ll be at least evaluating before writing anything in C: ELua and Armpit Scheme. They’re basically embedded versions of my two favourite untyped languages. Both support the STM32F4 Discovery board, which is based around an ARM M4F microcontroller from ST Microelectronics..

The reason I’m planning on using this microcontroller is that iẗ́’s available in a package with 2MB of Flash. This is attractive, because it should provide me with enough sample memory for what I’m tagetting without adding off-chip memory. The MIDIBox sample player project gets 4-8 sample voices streaming from an SD-card, and apparently the limiting factor is the speed of the card. The on-chip Flash should be significantly faster, allowing a guaranteed 8 voices or more.

Like said, this first project (there might be a second, more fully-featured sampler) is mostly aimed at playback of short, percussive samples, so more a sampling drum machine than a real sampler. It will have 8 outputs, and probably operate at 16 bits or less internally. D/A conversion will most likely be 24 bit, though, as audio-rate DACs are basically only available in that range now. TI make some cheapish eight-channel DACs that should be easy enough to interface with. I should have the STM discovery board in a week or two and be able to start coding, first using its internal audio and later with an external DAC. Other planned features are analogue filters for each output, a resampling circuit with distortion and a bucket brigade delay, and a built-in coffee maker. We’ll see how it goes.


Prospects for a DIY sampler

Looking over the music tech DIY landscape, one of the things I need that’s most blatantly missing is a sampler. My synth and sequencer needs are well-catered for, and analogue mixer schematics are readily available.

To the best of my knowledge, there are currently four documented DIY sampler projects on the net:

The first is the 8-bit Where’s The Party At?. It grew out of a project made for a circuit bending festival, and like most things from that end of the world is focused on glitchy nonsense (I say that with nothing but affection). It’s based around an Atmega CPU and an SRAM chip from Cypress; the firmware is written in C. The WTPA site mentions an upcoming version 2, but the last blog post about it is years old. Since it was originally aimed at circuit benders, a lot of whom don’t know much about electronics, it seems to be quite well-documented.

The second is the DeMIDulator, which is a four-voice digital synth that also samples. It’s open hardware, based on a Microchip PIC microcontroller. The firmware’s written in assembly.

The MicroGranny is a granular sampler based on the Arduino Waveshield and associated library (C++). It plays samples (one at a time) from an SD card and does granular madness to them. It doesn’t sample.

The last project is the Sample Player app for the MIDIBox platform. The hardware is basically just an I2S DAC hooked up to the MIDIBox Core module. It’s different to the others in that A) it doesn’t actually sample by itself, it only plays back samples from SD card, and B) it doesn’t allow much manipulation of the samples as it is. It is, however, much higher quality than the others, using CD quaity samples and 24 bit DACs. There are designs for two different DAC circuits on the MIDIBox site, but one is very old, and the other has recently been dropped from TI’s product line. Also, at least from looking at DigiKey, there no longer seems to exist such a thing as a through-hole DAC IC, it’s all surface mount.

None of these project fit what I’m looking for exactly. What I’m currently using my sampler for, mostly, is recording drum sounds and other one-shot noises from my synths. I need multiple outputs for this, and obviously some polyphony. Pitch envelopes are a must, and filters also. Once I’m done with my sequencers, I hope to start on this project more seriously. It’s definitely the hardest nut to crack, though, so I might do something easier first.

First steps: A sequencer

The first part of the project that I’m tackling is the sequencers. I have hardware synths and a sampler, but I’m currently using a Boss drum machine for all my sequencer. It works but it’s a bit limited, and its interface is not very immediate.

The obvious choice for a DIY midi sequencer is something based on the MIDIBox platform. The platform is based around a Core board which includes an ARM processor and the relevant MIDI/USB ins and outs. It allows easy interfacing with custom control surfaces through a number of simple input/output modules, most of which can be daisy-chained. In addition to being a modular hardware system, it’s also a set of software components based on the FreeRTOS realtime operating system that allows easily writing MIDI controllers, processors, and sequencers in C. All source and hardware schematics are available under an open source license, although commerical use is prohibited.

What I’m specifically going to go for to begin with is the MIDIBox SeqV4L sequencer/MIDI looper, which is small and optimised for live usage. It’s basically 48 buttons, 16 corresponding to the steps of the sequencer and 32 to select functions, and 64 LEDs, 16 that show the current step when the sequence is running, and 48 to show which buttons are activated.

There’s a more fully-featured sequencer, which has two displays, rotary encoders, and a lot more buttons, but I prefer the V4L for its more immediate design. It only allows two tracks at a time and requires an external controller to enter MIDI notes, but on the other hand it’s cheap enough that you can just build more as needed. In its current state it’s not ideal for drums/single-shot sounds, but the software is shared with the larger sequencer, which has a nice drum track mode, and a drum mode is forthcoming in the V4L software.

I built my first V4L a few months ago. It was a fairly easy build, but I’m not too happy with the control surface. It uses small, cheap buttons, and I think the panel is a bit cramped. So my first project is to build a bigger front panel. I’ve scrounged some very decent Alps switches from old Apple Extended II keyboards that I’ll use. I’ve made my first experiments with printing caps on a 3D printer at my local hackerspace and early results are encouraging, though for producing larger quantities it might be more feasible to cast them.

The MIDIBox platform also includes a module for a digital-analogue audio converter, and there is an app that allows you to use it as a simple sampler. I’ll get back to this as a sampler is the next project I expect to tackle.


Welcome to the provisory site for the Five Year Plan-project, to build a complete studio for making electronic music from DIY components over the span of the next five years.

Here, I plan to provide updates on my progress, as well as write about what’s happening on the music tech DIY scene.