[sdiy] Executing guest synthesizer code on stm32f4
ol.gillet at gmail.com
Tue Dec 30 18:22:04 CET 2014
This reminds of something I did a long, long time ago - an audio
plug-in framework for PalmOS...
A "plug-in" consists of a single rendering function whose arguments
are pointers to the input/output audio buffers, and a big "context"
structure containing the state of the sensors and UI, but also
pointers to utility functions like MIDI pitch conversion routines, and
to a big chunk of RAM unused by the main program and that the guest
code is free to use. The host fills this at startup - it's just
stuffing pointers and function pointers in a struct. Everything the
plug-ins needs to know to operate is referenced there. Everything must
happen in the rendering function.
To compile a plug-in, the developers will use a specific linker-script
in which the flash section starts at a well-defined address (say
0x08020000). The plug-in would only consist of the rendering function,
no startup code, nothing. You would just need to give away to
developers the linker-script and a header detailing what's available
at the big "context" pointer.
The host would just jump to the address at which the rendering
function is located (casting 0x08020000 as a pointer to
This is raw, good enough for effects and small chunks of code.
Don't bother with native code. Use bytecode/data and an
interpreter/graph rendering engine (like csound, pd, chuck or a FV-1
emulator...). What the users upload to your synth is just "data" or
"patches". Why I'm recommending this:
* The bytecode, or descriptive graph or whatever is going to be tiny,
which is a very good thing given the super low bandwidth you'll have
with your microphone <-> speaker upload mechanism.
* There's a good chance more people would write "patches" for your
engine. Very few people know how to write native audio DSP code, and
those who know might prefer just writing it for their own platforms
rather than your synth. In all these years selling
open-source/open-hardware synths and modules, I'd say less than 5 out
of 1000 customers are interested in running their own code on the
device. But if you come up with a GUI / development tool which makes
it easy to try and develop things on a desktop computer, more people
On Tue, Dec 30, 2014 at 5:16 PM, nvawter <nvawter at media.mit.edu> wrote:
> Hello All!
> I made a nice instrument based on the stm32f4 and I want people to be able
> to upload their own synth code into it via microphone. Has anyone got any
> suggestions for how to do this?
> I think in theory the idea is to reserve some space in the linker file for
> the "guest code" (plug-in). Then, use the main program to listen to the
> microphone, demodulate into the binary, then write the guest binary block
> into flash memory. Then, have the main program call the guest code, leaving
> all of the sensor variables (such as control voltage, knob inputs, patch
> select knob, etc.) in a magic place, have the synth code execute, return a
> block of data, and have the main program write that to the DAC.
> Questions I'm having are: how does the guest code know what ram locations
> are available? Should I statically allocate some RAM for the main program
> and some for the guest program? How do I use labels in the code to jump
> back and forth between funcions? E.g. if I write a "CV_to_pitch()" function
> and keep it in the main program, and I want the guest code to use that
> function. Should I make an intermediate table of where those functions are
> in the flash code, for when they move around, creating my own linker in
> Has anyone ever done this before? Are there any reference examples like
> this around? If anyone has any suggestions/tips/ideas, etc, please let me
> Also, I reached out to the stm32f4 subreddit with the same question, if
> anyone would like to respond there, or read the same request for help with
> different working:
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
More information about the Synth-diy