Patches as plugins

OWL
#1

I was trying to build OwlSim in Vs2012 on Win8.1 and ran into many issues. Eventually, I realized that all the errors were inside patches and if I don’t include the patches (includes.h) it builds just fine. (c++ is not my usual language.)

This got me thinking about why patches are in the code bases for the different libraries (OwlWare, OwlNest, OwlSim) and whether they can’t be separated out and each patch treated individually as a plugin (e.g. like a vst/au). OwlWare shouldn’t need more than 2 default patches, 1 per slot, intended to be overridden via OwlNest. OwlNest could be a “Patch Manager”, a library for patches that are imported (i.e. not compiled with OwlNest) where a user can send a selected patch to the desired slot on the Owl via Usb. OwlSim is trickier though. Can Vsts/Aus load external files? Maybe this is why patches can’t be fully plugin-ized.

I’m not new to programming but I’m a novice with hardware and audio programming. I could easily be missing some obvious, major downsides.

#2

Hi there!
We’d like to support dynamically loading patches into the device, and possibly into OwlSim, but there’s a couple of technical challenges to overcome.

Keep in mind that the patches are not just data files but compiled code.
To load them dynamically, the code has to be compiled to be position independent, and the ‘loader’, i.e. the firmware running on the device, must relocate it in memory before executing it.

This is something that operating systems do all the time, but supporting it in the OWL firmware will take a bit of work.

For the OwlSim it would be a bit easier because all modern OS’s have the ability to dynamically load code. After all, that’s how the VST plugin is loaded in the first place. However we would have to provide different binaries for every supported platform, i.e. Mac/Linux/Windows 32 and 64 bits.

#3

Ah, I see.
Thanks for entertaining my musings :slight_smile: