OwlProgram updates, native executable

OWL
#1

Two bits of news:
We’ve got a new OwlProgram release v21.1, incorporating all the recent changes and new features.

Summary of v21.1 changes:

  • SOUL integration
  • Maximilian integration
  • DaisySP integration
  • Added FAUST ‘key’ MIDI parameter (complements ‘freq’, ‘gain’, ‘gate’ and ‘bend’)
  • Added StateVariableFilter DSP class
  • Fixed Bus Error regression on legacy hardware
  • Automatically zero-initialise all heap allocations

Second: I’ve updated the ‘develop’ branch with some new features which makes it easier to test and debug patches for those of you that do so offline.
There are some new Makefile targets, and others that have changed:

  • make run used to compile and send a patch to run from RAM on the device. This has been renamed: use make load instead.
  • make ... native is a new target that will compile your patch into a native executable. Requires gcc or compatible compiler to be installed.
  • make run now compiles the native executable and runs it
  • make test will compile a test harness as a native executable and run it

The native binary can be invoked with a wav input and output filename (input should be 48kHz, 16-bit, 2 channels). This will run the patch, allow it to set default parameter values, then feed the audio from the wav file in and save the results in the same format.

To try it out, clone or checkout the develop branch of OwlProgram then make your patch as usual, but specify make ... run instead of make ... patch.

Note that this doesn’t work with SOUL patches yet, but Pure data, FAUST et c should be fine.

A future update will likely allow setting parameter values on the command line, e.g. something like patch -a 0.5 -b 1 in.wav out.wav

Do let me know if you find this useful, and if you have ideas/feedback for improvements!

Device restart after patch loading
#2

Have you tried debugging native patches, is it expected to work? Just thinking about the amount of frustration lack of this has caused in the past.

Also, it would be pretty cool if resource requests got proxied to reading files in working directory.

1 Like
#3

I’ve tried as far as sparking up gdb and putting some break points in. But I’ve not used it in anger. None of my patches have bugs, you see… :smile_cat:

#4

If you’re trying to get me to start reviewing your patches for bugs, try harder!

On a serious note, I mostly was interested in integrations troubleshooting.