Category Archives: sampler

Constructing a sampler, pt. 1

Starting way at the bottom, a digital sampler is basically a computer system with a few basic features:

  • Memory for storing sounds
  • An analogue-to-digital converter for getting sounds from the real world into memory
  • A digital-to-analogue converter for getting sounds from the memory into the real world
  • A method of playing back sound from the memory at will in a musically useful way (ie., triggers, MIDI notes)

(You can of course bypass the ADC and just pre-load the memory with sounds, in which case you get a sample-based synth or ROMpler)

This is very similar to a digital delay or looper such as Clueles, of course, which also stores sounds in memory and plays them back again, only such a system dispenses with the ‘at will’ part and just plays back everything in the order it came in.

If we modify the basic algorithm described in the Clueless document, instead of the simple three-step sequence, we need some state to know if we’re recording, playing back, or not doing anything. Ie.,

repeat: {
  if(RUNNING) {
    if(RECORDING) {
    else {

This obviously doesn’t have a user interface to change the state so it’s not much fun if you run it on a PC, but if we make an implementation with digital logic, we can implement the state by reading from e.g. a pair of flip-flops controlled by simple buttons. By ANDing the sample clock with the flip-flop which represents the RUNNING variable in the code above, the counters are only incremented when the flip-flop is on, We probably only want to fill or play the buffer once on every trigger, so we connect the overflow from the address counters to the reset of the flipflops, meaning that when we reach the end of the buffer, playback or recording stops. In code, this would mean resetting addr to 0 once it reaches the end of the buffer.

repeat: {
  if(RUNNING) {
    if(RECORDING) {
    else {
    if (addr >= LENGTH) {
       addr = 0;
       RUNNING = false;

This sampler has some serious limitations, of course: It can only store one sample and it can only play it back from the very beginning to the very end. A variable clock would allow for simple repitching, much like varying the playback speed on a delay or tape recorder.

The addition of a trigger circuit so you could enable recording but only start it after the input reaches a certain threshold would arguably make it useful for sampling percussive noises. A use case for this is making drums with monophonic synths without using a whole synth for a single drum sound; it’s also possible (and easy) to add battery-backup to SRAM, meaning that you could have non-volatile sample storage.

I’ve attached a schematic sketching the above design, minus this trigger circuit. Note that it is untested not all signals are properly connected and that buttons, clock, analogue circuitry, etc., are not shown. The Clueless schematic is more complete if you want to try to build this, but most things should be obvious.

I’ve used a 112 dual J/K flip-flop for the state, push buttons could obvious be attached more or less directly to this. The ‘112 has two outputs per flip-flop: one that’s high when the flip-flop is on, and one that’s high when it’s off. Since the DAC write strobe is derived from the high-when-on output, we can use the other output for the chip select of the DAC, and conversely for the ADC.

It seems that the sequencing parts of Clueless can be entirely foregone since the DAC and ADC aren’t sharing the memory bus, By NAND’ing the clock with the output from the flip-flops, we offset the sample counting pulse (triggered on a rising edge) and the R/W pulses (falling edge). Once again, this is untested, no fitness implied, etc., etc. Do let me know if you try it, though.


Various updates

So a few things have happened in the two months that have passed since my last blog post.

I built a MIDIBox Seq V4. It doesn’t have a proper front panel yet, is just Wilba’s PCB mounted on a piece of acrylic. It is, however, functional and great as it is, so for the moment I’m crossing sequencing off my list. I’ve also got the parts for a MIDIbox FM synth which is polyphonic, so maybe I’ll have my first piece of open hardware music soon.

The sampler is progressing in various ways. A friend of mine is designing a board based on the STM32F4 with a few megabytes of external SRAM. It will be ready, hopefully, within a few months. This should be a good platform for a sampler, and also for effects which need more working memory than microcontrollers have on-chip.

Another interesting development is the port of the MIDIbox software to the STM32F4 Discovery board. This is a cheap development board based on the same Cortex M4F from ST that my friend is using for his board. The chip on this is faster than the LPC1769 used in the regular MIDIbox core, and has a number of instruction set extensions as well as hardware floating point that make it much more suitable for DSP tasks than the LPC1769.

The Discovery board also has an onboard audio rate DAC that the MIDIbox software can address, so it’s already a good platform for making synthesizers if you can tolerate C. As mentioned previously, there’s already a SD card based sample player that could provide a starting point for a proper sampler. This is my summer project. It’s not the variable-clock, 12-bit S900 recreation I really want to see, but it would certainly be useful for certain things, like a PCM drum machine.

Speaking of drum machines, I was pleased to see the Sonic Potions LXR drum machine sell out the first 100 kits in hours. This community is doing great things, and I look forward to seeing the developments.

Sampler progress, again

So I’ve been braining and going over datasheets, service manuals and schematics in most of my free time recently. The E-Mu Emulator service manuals are a great, read, BTW.

I’ve come up with an architecture that’s quite close to the S900, only a lot less chips are needed since we now have faster microcontrollers, DACs with built-in buffers, etc.

In fact, I think most of the digital parts could be done with just three chips.

The first is the microcontroller. The STM32F4 has enough on-board timers that you could run one per voice in an 8 voice system and still have enough left over for house keeping, but you might be able to get by with one for all the voices. At any rate, the idea is that the timer generates an interrupt in a way that divides down a high frequency clock to the desired (variable) sample rate, per voice.

This interrupt moves a sample from memory to the DAC. Since I find the volatility of memory on old samplers one of their most frustrating aspects, non-volatile memory is a primary requirement for me. You can use Flash or battery-backed SRAM, but I’m very attract to MRAM for its space age characteristics. You basically use it like you would SRAM, no need for erasing before writing and such, but it doesn’t require power to keep it’s data. Meaning, no internal batteries are needed. At 30 euro for a 16 megabit chip, though, it’s twice as expensive as regular SRAM. At 50 KHz sample rates, 16 Mbit is 20 seconds of sample time, minus some overhead. 20s is OK for this project, 40s more than enough.

The above chip is paralel, which means it’s extremely easy to use: just connect the address pins to GPIO pins on the µc, and the output pins to the input pins of DAC. I could use one single channel DAC and some sample and hold trickery, or a DAC per voice. I’m going for the latter. Just a few pins for the selecting which DAC to write to, loading the outputs, etc.

The missing bits, of course, is a paralel ADC and some more DAC channels to generate CV for the analogue filters, but this is the jist of it.

Sampler progress

A very interesting thread cropped up on Gearslutz recently, describing the various ways digital synthesizers and samplers implement sample/wavetable playback.

The previous approach I had in mind for my sampler was to use a regular audio codec, some 24 bit, 44.1 KHz thing, attached to an STM32M4F microcontroller. This would work.

What would be more fun, though, is to try and emulate an older, 12-bit design. Going by the taxonomy in that thread, I quickly settled on a high frequency clock, divide-by-n. The basic approach is to use a constant clock well above the desired sample rate, and use a counter or divider to derive the desired rate from it. So if you have a constant 8 MHz clock, you output a sample from your buffer every 1000 clock ticks for an 8 kHz output rate — if the sound was sampled at 8 kHz, this means it’s played back as it was recorded, but if it was sampled at, say, 11 kHz, it will be played slightly slower, resulting in a lower pitch without interpolation.

Looking at the schematics in the Akai S900 service manual (available online — give it a google), it uses an external counter to divide the clock, and a couple of 4×4 bit register files to feed a parallel input 12 bit DAC.

This is all well and good, and could be redone as most of these chips are still available, but things have improved a little since 1986. The STM32F4 has a bunch of on-chip timers that can be used instead of external counters, and buss bandwidths are good enough that you can use SPI DACs for 8 voices and 24 CV outputs (analogue filter/VCA control). I’ve sampled a 12-bit four-way DAC from TI (DAC7615) that should be just about good enough for up to ~40 kHz output rates that would work for one voice + control of one of the simpler Shruti filter boards.

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.