erichdonahue.com

Selected Work

Music technology case study

FxPatchSDK / Endless DSP

A development fork of the Polyend Endless SDK for building custom C++ guitar effects, with real validation scripts and a build loop that goes from source to a flashable patch.

GitHub repository

What it is

FxPatchSDK is a development fork of the official Polyend Endless SDK, for writing custom guitar effects as compiled C++ patches that run on the pedal’s Cortex-M7. The repository already ships fourteen effects to build from and compare against: a Klon Centaur, a couple of Big Muff variants, a Tube Screamer, a Phase 90, Wah, Chorus, Harmonica, and a handful of others. I did not write those. What I use the repo for is everything around them. There’s a JUCE wrapper so a new patch can be auditioned as a VST before it ever touches the hardware, three validation scripts I lean on more than I’d like to admit, and a build that goes from source to a .endl file I can actually flash.

Why I built it

I like the pedal, and I wanted to write my own effects for it rather than only use the stock ones. The catch is that a DSP patch is creative work sitting on top of embedded firmware, and firmware does not forgive “I’ll remember what I changed.” So the repo carries source control, a build I can repeat exactly, and validation that has to pass before anything gets flashed to actual hardware, none of it glamorous and all of it the reason I can come back to a patch six months later and still know what it does.

The build loop

make TOOLCHAIN=/usr/bin/arm-none-eabi- compiles a patch for the Cortex-M7 target. Before that, three scripts do the checking I would otherwise do by ear and by guessing: check_patches.sh for syntax and lint, check_arm_build.sh to confirm the ARM build actually compiles, and analyze_effects.sh for control-law and headroom analysis, which is the one that tells me whether a knob curve is going to feel right before I turn it. The JUCE wrapper builds the same patch as a VST3 or LV2 plugin, so I can hear a change in a DAW without waiting on a USB-C flash cycle every time.

What I learned

Firmware work punishes sloppiness a plugin project would just shrug off. A patch that compiles clean and still misbehaves on the actual pedal is exactly the failure mode check_arm_build.sh and analyze_effects.sh exist to catch before it happens on hardware I only have one of. Auditioning a patch as a VST first turned out to be the bigger speed-up of the two: most of what makes an effect feel right or wrong is audible long before it needs to run on the actual chip.