Patch Programming Guidelines

To use the OWL Patch API, all you have to do is create a class that derives from Patch and implement the processAudio() method.

Memory Allocation

OWL patches should preferably not use dynamic memory allocation, neither malloc nor new. Audio buffers should be allocated using the Patch::createMemoryBuffer() method. This will return an AudioBuffer object, from which a float array can be retrieved.

Memory allocated with createMemoryBuffer() is managed by the patch processor, and should not be collected by the patch (don't free or delete!).

Recent versions of the firmware supports user allocated heap memory (new/delete and malloc/free). If used, then all dynamic memory must be allocated in the patch constructor, and the utmost care must be taken to free all used memory in the destructor.

Library Support

All functions defined in the standard math.h library are available, but processing-intensive functions should be avoided if possible, or their use should be minimised. The ARM CMSIS-DSP libraries are also available to use (currently in OwlWare only), with very useful functionality including FFT, FIR and convolution. Some standard math.h functions are implemented in OwlWare using ARM optimised code:

  • sin() / sinf()
  • cos() / cosf()

Language Standard

OwlWare is written in standard C++ compiled using the Gnu ARM gcc cross-compiler, which supports many C++0x and C++11 language features. If you want your patches to compile for other platforms (e.g. in OwlSim), you need to be more conservative with newer language features. In particular, Visual Studio C++ doesn't support some C99 features such as variable length arrays.

Naming Convention

Classes should be named in UpperCamelCase; methods, functions and variables in lowerCamelCase.

Patches should be named after their function, e.g. FuzzPatch, and be fully contained in a .hpp file called e.g. FuzzPatch.hpp.