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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s