How to make a natively written patch available

I’ve made a patch I want to share, written in C++.

I have been developing via linux and the make dfu command, uploading firmware directly with my own “factory patch” However I suspect there are other ways to do it via sysex.

How does this work? I built the FirmwareSender app but I can’t figure out how to make it work. It also seems to have the ability to upload a patch into a single slot, how would I build a patch that can be uploaded this way? I’ve used some other features of the CMSIS library that would require being linked in as well.

I can just make the OwlWare.bin available but it may not be ideal if people want to use other patches at the same time.

hi @clevijoki,

im not 100% sure i understand your question fully, but you can share you patches online if you want using the online patch library here: https://www.rebeltech.org/patch-library/patches/latest

if what you are looking for is an alternative way to program your owl device, you can use FimwareSender for that. Either compile and run it from command line yourself or you can also check out how, a virtual machine that will support compiling and deploying polyglot patches to owl devices eventually. It is work in progress but should work for C++ patches out of the box: GitHub - bfabricius/howl: Hypervised OWL build environment for audio DSP patch compilation and dep

There should be enough documentation to get you going :slight_smile:
Ill be adding plenty of new features whenever i have the chance, also programming user patches to specific user slots.

Cheers,
Ben

I can’t use the online patch compiler, as I link with other SIMD features that it does’t allow me to use. e.g. I use q7_t and related CMSIS DSP functions.

If you look at the firmware source code there is a libs.mk that requires adding new CMSIS objects in there:

I can’t force those into the online compliler (I can try including them .c files as relative paths but it fails with that, it seems like permissions won’t let the online compiler read the files)

At some point though, the online compiler genreates a sysex file that can be uploaded, if I could just generate that myself via the make files somehow that would be good enough. Technically, what does the online compiler do here to just compile the object? is it making a shared lib?

I can also make the firmware (OwlWare.bin) into a sysex file via FirmwareUploader -file option. But then I haven’t found a way to actually upload it to the pedal to ensure that it works correctly, but that could just be my misunderstanding of how to run FirmwareUploader.

Hiya!

The online compiler runs OwlProgram, which is our build tool. It creates a ‘dynamic’ patch that the firmware can load into RAM and execute, and which can also be stored in flash (in what we call a user slot). It is this dynamic patch that is wrapped up as a sysex that you can download from the patch library.

HOWL is @bfabricius project which is designed to make it easier to run OwlProgram by wrapping up all the dependencies in a VM.

If you compile offlline with OwlProgram, through howl or directly, then you can control all the compilation settings yourself.

If you could post a link to your patch code then we can maybe offer more advice.

best,

Martin

1 Like

The code is here:

I will try OwlProgram, I should be able to modify it to make it work.

So is the dynamic patch compiled to run at a specific memory address then, and it just overwrites that ‘user patch’ memory address?

Yes that’s right. The dynamic patch is linked to SRAM address 0x2000c000. Loading the patch doesn’t change the nested interrupt vector, so all interrupts are handled by the main firmware. Communication between firmware and dynamic patch is done through the ProgramVector which is a struct in shared memory.

OwlProgram manages all this, and produces a binary which can simply be copied (by the firmware) to the correct address then branched to.

I got it to compile by first adding this near the top of the patch:

#define AUDIO_BLOCK_SIZE 128
#undef abs
#undef max

and then adding the file NESPatch.hpp to a directory along with the dependencies:

arm_abs_q7.c
arm_float_to_q7.c
arm_q7_to_float.c
arm_copy_q7.c
arm_max_q7.c

I’ve got a copy of it here: https://www.rebeltech.org/patch-library/patch/untitled_d0160b4a9e47
Unfortunately using the CMSIS DSP library directly means that it won’t compile for Javascript - but it should run fine on the hardware!

Looks interesting - and I see we use the same random shift register!

It would be good if you could dynamically allocate memory and use getBlockSize() instead of relying on AUDIO_BLOCK_SIZE being correct.

hth,

Martin

ps I compiled it, with all files in a folder called NES, using this command:

make PATCHSOURCE=NES PATCHNAME=NES clean run

(requires renaming NESPatch.h to NESPatch.hpp)

1 Like