Hi all,
I spent a couple of hours trying to follow this tutorial to build C++ patches on Windows:
https://github.com/RebelTechnology/OwlProgram/blob/develop/README.md
I ended up getting a test tone patch running on my Wizard (I plan on eventually getting the Lich).
Given that:
- the makers of the OWL platform are pretty much absent these days, and everything is falling back on @antisvin (seriously, thank you SO MUCH for everything you’re doing around here, absolute MVP)
- the readme has not been updated in a while and some dependencies have changed
- not everybody might know about it all, being able to code patches in C++ doesn’t mean being able to troubleshoot the issues at hand (I happen to be a software developper, with my own weaknesses clearly, I had no experience with MAKE before)
I figured I would give back to the community and contribute with my findings to run a C++ patch on an OWL device on Windows in 2026.
I’ll simply copy the content of the readme with my own notes. I removed all content related to Pure Data, Faust and whatnot. I would offer a pull request of some sort, but I’m unsure it would go through.
Instructions
Prerequisites
- gcc arm compiler (to make patch binary) ← There are new versions of the gcc ARM compiler, the link isn’t really valid anymore, here’s the one I got: https://developer.arm.com/-/media/Files/downloads/gnu/15.2.rel1/binrel/arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi.zip You specifically need a bare-metal version, not one to build for Linux devices.
- FirmwareSender (to make, load and store sysex) ← I downloaded the last released build for Windows, from 2015: https://github.com/pingdynasty/FirmwareSender/releases/download/v0.1/FirmwareSender-windows.zip I might eventually try and build v0.2 for Windows.
- emcc (to make web) ← I fully skipped this step, given that I’m not building for web. I had to unplug the corresponding section in the makefile, more on that later.
- faust2owl (to compile FAUST patches) ← skipped
- The Heavy
hvcccompiler (to compile PD patches) ← skipped - The
soulcompiler (to compile SOUL patches) ← skipped - gcc native compiler (to test locally) ← probably not necessary, I’m not sure what building locally means. Can an OWL patch run natively on Windows?
- On Windows, you’ll need a MAKE utility. ← You need this, get it from http://sourceforge.net/projects/mingw/. Follow the installers instructions, everything will be installed at C:\MinGW. You also need Cygwin (https://www.cygwin.com/setup-x86_64.exe), install it at C:\cygwin64. (Note to self: maybe Cygwin can handle all of the make shennanigans instead of MinGW + cygwin)
- Very important: you need to set your environment variables, for these to be properly taken into account. On Windows, search for “env”, and choose “Set environment variables for this account”. In the first box, select the PATH line, click “Modify…” then “New”. Add C:\MinGW\bin\ and C:\cygwin64\bin\ to two separate lines. Click OK as many times as needed. Log out of your account and in again, for these changes to be taken into account. Otherwise you might lose hours of your time not understanding why your compilation doesn’t work (I’ve been there).
Side note: Why are these MinGW and Cygwin needed? It’s because by default, Windows and Linux do not share the similar suite of (command-line) tools necessary to copy files, write in console, etc. For example: mkdir is the command-line function for both Windows and Linux to create a folder, but it differs in critical ways for each platform. Cygwin is a suite that comes with a whole bunch of executables that precisely replicate on Windows the original behaviour on Linux.
Side side note: What is MAKE? Make is a program that, believe it or not, simplifies C++ compilation. It can automate tasks, for example to build lots of files at once, run automated tests, run custom tasks like “build this patch”, “build all common components needed for all patches”, “clear the previously generated binary files”, etc. It is easily accessible on Linux and relies on GNU tools, hence why it is required to get MinGW and Cygwin as MAKE utilities, to bridge the gap between GNU/Linux and Windows - otherwise, make files would need to coexist in different versions for Windows and Linux.
- You also need git, to be able to download the code for everything. Even though it looks a bit scary at first (again, I’ve been there), git is highly highly convenient. Git - Install for Windows. Check that is properly installed by right-clicking in an explorer window, and choose “Show more options”, then you should see git bash as an option.
- Finally, a nice app to write your pretty code is more than convenient, I’m using VSCode which is free.
You’ll also need to open compile.mk and point TOOLROOT to your gcc installation directory, using a path string without spaces (such as using 8.3 filenames). ← You need to do this: once you’ve downloaded the arm GCC compiler (step 1), put its content in a short path with no spaces, such as C:\GNUarm. compile.mk is a file at the root of OwlProgram, you’ll have it point to your gcc ARM compiler, more on that later.
Preparing the environment
This has been done on a Ubuntu server 18.04 Windows 10 
Base tools
In an empty folder of your choice, right-click → More options → Git Bash… and enter the following commands
$ git clone https://github.com/RebelTechnology/OwlProgram
$ cd OwlProgram
$ git submodule init
$ git submodule update
At this point, I would open the whole OwlProgram folder in VS Code.
Edit OwlProgram/compile.mk and point TOOLROOT to where arm-none-eabi binaries are installed. In my case:
TOOLROOT = C:\GNUarm\arm-none-eabi\bin
Compile FirmwareSender
You can use the older release downloaded on step 2. Place the .exe file in Tools\FirmwareSender\FirmwareSender.exe.
Other changes for Windows in 2026
In the file Makefile, change line 72 to the proper path to FirmwareSender on Windows:
FIRMWARESENDER ?= Tools/FirmwareSender/FirmwareSender.exe
You can also disable web compilation if you’re not using it, to avoid unnecessary error messages, by adding a # at the beginning of line 114:
# @$(MAKE) -s -f web.mk libs
In file compile.mk, search for the first TOOLROOT and define it to point to your arm GCC folder:
TOOLROOT ?= C:/GNUarm/bin/
In the same file, look for line 114:
CPPFLAGS += -nostdlib -nostartfiles -fno-builtin -ffreestanding
Replace it with:
CPPFLAGS += -nostdlib -nostartfiles -fno-builtin -fpermissive
Some explanation: -ffreestanding is not possible anymore when using gcc arm and the math library, it is one of the breaking changes introduced since 2023 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814)
Furthermore, there is a very nagging issue with nested extern declarations in the version of the MSIS dependency in OwlProgram (see https://github.com/ARM-software/CMSIS_5/issues/1484), which might have been fixed in version 6 (it’s a different github repo, it might be possible to just copy and paste and have it work). In the meantime, it is necessary to allow for these to be treated as warnings and not errors, with -fpermissive. You will get a lot of identical warnings when running make libs, but the code will compile.
If you’re using VS Code, you can set some additional settings by adding a folder named .vscode at the root of the projet (if it doesn’t already exist), add a c_cpp_properties.json file (if it doesn’t already exist) and paste the following content, to make sure that the paths to compilers are correctly set by VS Code, and that IntelliSense doesn’t go mad trying to figure out where your includes go:
{
"configurations": [
{
"name": "Win32",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE"
],
"compilerPath": "C:\\GNUarm\\bin\\arm-none-eabi-g++.exe",
"cStandard": "c17",
"cppStandard": "gnu++14",
"intelliSenseMode": "windows-gcc-arm"
}
],
"version": 4
}
Finally, for the sake of simplicity, I added a line /Build/** to .gitgnore.
Make targets
Important: If you’ve followed the instructions precisely so far, the MAKE tool made available to you is actually not called make, but mingw32-make (which comes with MinGW, but note to self: a MAKE tool could be installed with Cygwin in a later update). Everytime you see a command such as make libs, you actually have to use mingw32-make libs.
I recommand you use the Terminal in VSCode, which is very convenient.
In bold are the commands that I’ve used so far:
- make libs: build library archives
- make patch: build patch binary
- make sysex: package binary as sysex
- make load: upload patch to attached OWL and run from RAM
- make store: upload patch to attached OWL and store in FLASH
- make web: build Javascript patch
- make clean: remove intermediary and target files
- make realclean: remove all (library+patch) intermediary and target files
- make size: show binary size metrics and large object summary
- make native: build a native format binary of your patch
- make test: build and test a native format binary of your patch
- make run: build and run a native format binary of your patch
- make map: build map file (Build/patch.map)
- make as: build assembly file (Build/patch.s)
- make help: print target information
- make docs: generate HTML documentation
Before you compile a patch you must first call make libs. This will create archive files in the Libraries and Build folder which will be reused each time you compile a patch. The archive files must be updated with make libs if you make any changes to the library source code (e.g. with a git pull), or to the compiler. If you don’t have emscripten installed, then the second part of make libs will fail. You will still be able to compile normal patches, but compiling to Javascript with make web will fail. ← see above
Make sure to do a make clean before compiling a new patch, or add clean to your make target (e.g. make clean patch), otherwise the previous patch name will be retained. Other wonky stuff can happen if a previous compilation did not go well, so it’s a good idea to make clean then make libs if something went wrong.
Make options
- PATCHSOURCE: patch source directory, default
PatchSource - PATCHNAME: specify name of patch, default
Template - PATCHCLASS: name of patch class, default
TemplatePatch - PATCHFILE: name of main patch file, default
TemplatePatch.hpp - PATCHIN: number of input channels, default 2
- PATCHOUT: number of output channels, default 2
- SLOT: user program slot to store patch in, default 0, use with
store - TARGET: changes the output prefix, default ‘patch’
- PLATFORM: changes the target platform: OWL1, OWL2 (default) or OWL3
All files for a patch must be copied to the PatchSource directory. Take care to put only files required by the patch you want to compile here.
If you follow the naming convention above (e.g. XyzPatch.hpp) then you don’t have to specify PATCHCLASS and PATCHFILE, they will be deduced from PATCHNAME.
This means that, if you don’t change any other variable in compile.mk, you can imply add your patch files in the PatchSource folder. By default, it is required that the .hpp file ends in “Patch”.
Note that when storing user programs, the legacy OwlWare firmware has four user defined patches, numbered 37 to 40. These correspond to slot number 0 to 3. For OpenWare firmwares, the slots are numbered from 1 and up.
Building C++ patches
First copy all patch files to PatchSource folder, then issue the appropriate make patch command.
Example: Compile and load the TestTone patch, defined in file PatchSource/TestTonePatch.hpp (It’s not actually in this repo, get it from https://www.rebeltech.org/patch-library/patch/Test_Tone#Source and copy it to PatchSource. It will compile, but you’ll get a warning because of a deprecated function, you can fix that as a first exercise!) as class TestTonePatch: make PATCHNAME=TestTone load. You must connect your OWL device to your computer.
Final notes
TODO
- Test the
make storecommand - Fork the repo
- Try to update MSIS to version 6
- Update readme
- Try with Cygwin only (some packages might need to be selected during installation)
- Try to build FirmwareSender v0.2 on Windows
- Finally code the double LFO with attenuators that I wanted to use the Wizard for
- Take your feedback into account!
Hope that helped!
Cheers
