HI everyone!
got my first Daisy today ( a pod), and I like it very much. Currently I am an DSP dev with my own iOS app, but I have a crush on more lowlevel environments, worked with teensys and avr’s in the past.
Now my question: can I store executable code on an SD card and retrieve the data, load it into memory and execute it? can the CPU execute code from ram?
Best,
Paul
thanks!
I’m interested in setting up an environment that enables to use plugins.
I’ll draw a rough outline here, perhaps other people are interested to join this effort.
the idea is to have a freely expandable mulitfix unit.
So the executables on SD have a defined format, with data on top.
The Daisy doesnt need to know about the params that much:
The main program gets params over midi and stores these in the plugin data area.
The params then are generated by an editor (pc/mac/ipad)
For the first version all params are just floats, range checking only by the plugin process()
The plugins then should have an info header on top, to provide info to our main host.
The inti() function comes after the params, and gives back the adress of the process() function.
Example plugin format;
int32 pluginSystemVersion = 0
int32 numberOfParams
float32 Param 0
. . . .
float32 Param (numberOfParams-1)
function int32* init(SR) — init plugin, return adress of process function
function void process( float **in, float *out, int bufSize, midiConnector midi)
Every plugin exist of
-a binary with format simular to above, which auto informs the host about its function adresses and number of params.
-a descriptor file for the pc/mac/ipad app (in short: editor) that give names and ranges to the params.
Our mainhost has a min app that executes slots, wherein plugins are loaded. Every patch consists of a list of plugins to load and the param values associated.
At patch load, the mainhost sends the param settings over midi to the editor.
Incoming midi is forwarded to the plugins. for adressing the params in plugs in the slots a simple midi dialect can be made, which is used for both directions in between daisy and editor.
So far my musings, I’m interested in cooperation for this very much.
Hey Paul!
You should be able to use the SD card to load binary file to the Daisy.
Is the idea to share firmware with people? 
It’s also possible to do this Daisy Web Programmer
1 Like
Hi Takumi,
the idea is to be able to switch fx without flashing the daisy, ideal would be to be able to load 3-4 little fx at once, triggered by remote MIDI PC or browsabe by continous controller. And ofcourse the SD card then could carry hundreds of different fx… And yes: they ofcourse then could be shared amongst users…
A bit like the MOD but then without the overhead. Im not sure whether there is enough ram on the pod to make it really work. It is still just an idea for a hobby project.
It sounds like checking out these two resources/guides would be a good start:
Could you tell me more about MOD? I haven’t heard of this synth (or effects).
1 Like
MOD is a linux based opensource pluginloader
Here a way to call dynamically loaded code is discussed:
1 Like
Hello,
Take a look at these threads about Owlsy - @antisvin has ported it to a few of the daisy platforms:
I think it does some of what you’re describing, in that it has a base firmware that can load different patches.
Cheers
2 Likes
Owl specs looks nice!
Are there templates/example for non-faust plugs? faust is nice and all, but I’m used to c++
Have a look at C++ docs
Regarding patch loading on OWL, they are standalone programs that get executed from a FreeRTOS thread. MCU peripherals are not accessed by patch directly, instead of that there’s a shared memory section that is used by firmware and current patch to exchange data and various function pointers. This allows firmware to provide info about CV and audio, MIDI data, available memory for dynamic allocations, etc. Firmware provides a pointer to function that blocks on RTOS mutex until new audio block is ready which synchronizes patch code to audio DMA callback.
1 Like