[sdiy] Executing guest synthesizer code on stm32f4

Olivier Gillet ol.gillet at gmail.com
Tue Dec 30 18:38:01 CET 2014

Other "easy" options I can think of:

give away the entire source code of your synth, minus all the audio
rendering code. With a linker script in which flash starts at

Use a bootloader that can either jump to, say, 0x08008000 (official
firmware) or 0x08080000 (alternative firmware) after initialization.

In effect, a "plug-in" is just a full-blown alternative firmware.

Very few headaches, but lots of code duplication (which can be bad if
code size is an issue) - and this exposes your non-audio code.

On Tue, Dec 30, 2014 at 6:22 PM, Olivier Gillet <ol.gillet at gmail.com> wrote:
> Option 1:
> This reminds of something I did a long, long time ago - an audio
> plug-in framework for PalmOS...
> Roughly:
> 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
> MyRenderFunctionType).
> This is raw, good enough for effects and small chunks of code.
> Option 2:
> 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
> will come!
> http://www.pjrc.com/teensy/td_libs_Audio.html
> http://www.shbobo.net/
> 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
>> effect?
>> 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
>> know.
>> 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:
>> http://www.reddit.com/r/stm32f4/comments/2qtnsx/how_would_i_do_this_upload_blocks_of_binary_code/
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at dropmix.xs4all.nl
>> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy

More information about the Synth-diy mailing list