Hi,
I have finaly mi Daisy Pod playing PD patches.
Could I have several patches on Daisy and switch between them? If it is possible, how could I do that?
Thanks
Hi,
I have finaly mi Daisy Pod playing PD patches.
Could I have several patches on Daisy and switch between them? If it is possible, how could I do that?
Thanks
I apologize for insisting but I would like to know if it is possible to have several patches on Daisy seed and switch between them or not.
Thanks in advance
Since you insist: While ANYTHING is possible, I don’t think there is any practical way to load multiple PD patches on any Daisy platform.
Thanks! Good to know
I wouldn’t be that sure on that, at least in Orac it is possible to load multiple patches and switch them. Anyway a workflow like this, with a Mainpatch and Subpatches needs alot of Preparation.
Can Orac run on Daisy? That would be cool. I thought it needed an Operating System and would be difficult or impossible to port to Daisy.
No.
Orac requires Pure Data and a full Operating System. The Daisy is a microcontroller that can basically only run 1 piece of code at a time.
Using pd2dsy (and hvcc) you can convert a Pure Data patch, that normally runs on a regular computer, into c/c++ code that can be compiled to run standalone on a Daisy board.
While we can upload the program to different parts of the Daisy memory, it is currently not possibly to upload several programs at the same time and switch between them.
I assume this could be possible, as this is what OWL for instance also does on a similar STM32 microcontroller, but I’m not aware of the details of how we can accommodate this for Daisy as well.
Maybe I was not clear. I don’t want them running simultaneously but having them on my daisy and switch stopping one and loading another without a computer.
You’ve got this slightly wrong - OWL builds and loads patches targeting the same area of memory. It loads a specific patch at run time and can replace it, but in order to get this working it runs FreeRTOS and patch execution is performed from a separate OS thread.
Unlike libDaisy firmware, an OWL patch is a standalone executable that is compiled without access to hardware. Only firmware side (OpenWare) can do that and it uses the same STM32 libraries as libDaisy. In order to communicate with hardware there’s a shared memory area that is known both to patches and firmware and is used for bi-directional IPC, exchanging parameters and audio buffers, etc.
As you see, this is far from trivial.
Thnx for expanding on this! I have next to no architectural knowledge about OWL and Daisy and was just inferring from past experience with the platforms. Mainly figuring “from a hardware perspective it should be possible”, however of course Daisy is not at all set up to work in the same way as OWL so not directly applicable right now.
Does FreeRTOS and this extra OS thread cause much overhead?
It was clear, just not possible considering how Daisy firmware works.
Could be possible if you run OWLsy though …
Not at all! It’s configured to run with cooperative threading, so audio code doesn’t get preempted. Its task switching is written in optimized assembly and there’s a dedicated interrupt on ARM that is used to enable context switching.
There are some other threads, but they only run occasionally when audio callback is done. So we can load CPU with audio to something like 98% and it’s still stable (maybe H7 needs a bit extra room due to cache misses making performance less predictable)
The implementation of this on OWL is rather elegant, because it leads to audio patch blocking on mutex by calling a function pointer provided by firmware to wait for next block of audio, but it doesn’t know anything about this as the actual code is given by firmware.
No as mentioned by others before, Orac doesn’t run on Daisy. I just took it as an example of that nested Subpatches concept.