Roadmap · updated 25 July 2026
What works, and what doesn’t yet.
Most product roadmaps are a list of promises. This one is mostly a list of things that are missing, because at this stage that is the more useful half.
- Working today
- 9
- In progress
- 4
- Shipping dates
- none
No dates, deliberately. One person cannot forecast honestly, and a missed date on a roadmap does more damage than an empty column.
Running on hardware. If it is in this column and it does not work for you, that is a bug.
Behringer X32 family over OSC
Handshake, /xremote subscription, live state read back, auto-reconnect.
Soundcraft Ui12 / Ui16 / Ui24R
Channel 1–16 faders and mutes, FX 1–4 mutes, over the console’s own WebSocket.
Three mapping templates
Solo boost on hold, talk mode on hold, mute on tap — each with capture and restore.
Confirmed writes with retry
Three attempts, then a red flutter. The LED never claims a change the console did not acknowledge.
Conflict model
An inbound value that differs from the one requested cancels the pending write. Front of house always wins.
Learned offsets
If the engineer corrects you mid-hold, the next press applies the difference.
Captive-portal setup and local web UI
No app and no cloud to get a pedal running. The config page is served from the pedal’s own flash.
Self-replication and browser flashing
A working pedal writes a sanitised image of itself onto a blank board over Web Serial.
Local device API and OTA updates
Documented HTTP and WebSocket interface, plus firmware updates over Bluetooth.
Started, not finished. These are the things standing between here and a product someone can buy.
Reference build: parts list and enclosure
One exact BOM with no branching, from parts actually bought, plus a case that survives being stood on.
Blocks the build guide from being genuinely followable by someone who owns nothing yet.
Prebuilt firmware releases
Tagged binaries so a first flash does not need a toolchain install.
Once this lands, first-time flashing moves into the browser like cloning already has.
Compatibility and reliability matrix
Which console firmware versions have actually been tested, on what date, with what result.
A compatibility claim without a tested version and a date is not a claim.
Mobile app
The companion app that configures Extended over Bluetooth. The licensing backend exists; the app does not.
This is the single thing blocking Extended from being purchasable.
Wanted, plausible, not started. What gets built next depends heavily on who asks for what.
Behringer X Air and Midas MR18
XR12, XR16, XR18 and MR18 speak a protocol close to the X32, so the driver work is smaller than it looks.
Currently the most requested next console, and the strongest candidate for the next real feature.
Guarded scene and snapshot recall
Scene recall is destructive by nature, so it needs a two-step gesture and a preview of what changes before it is safe to ship.
The obvious next template. It does not exist today in any form.
Tap tempo
Straightforward on paper; the question is whether it is reliable enough over the network on each console to be worth having.
Shared mapping presets
Start as plain files in a public repo rather than an in-app browser — data, not infrastructure.
Operator lock for hired-in rigs
A way for an engineer to hand a musician exactly the controls they are happy to hand over, and no others.
Needed before this makes sense for worship and production teams.
Saying no in public is more useful than leaving it ambiguous. Ask if you disagree — some of these are only a “no” because nobody has needed them.
MIDI output
This is a network device. The action names exist in the schema and do nothing; there are good MIDI controllers already.
A subscription for core operation
Never. Anything that stops working when a payment lapses is a rental, and that is not what this is.
Cloud sync or a required account
Core has to keep working on a venue network with no internet, so a login can never sit between you and your own pedal.
Selling assembled pedals
Selling finished radio equipment in the EU brings CE, RED, WEEE and product liability with it — a different project, not a bigger version of this one.
Someone else building and selling them is welcome; the hardware is documented for exactly that.
Feedback
What gets built next is mostly decided by who asks.
With a queue this size, one clear report from someone running a real rig genuinely moves things up the list. That is not flattery — it is how a project this size has to work.
Something is broken
Open an issue with your console model, its firmware version and what the LED was doing. That last part usually identifies the problem on its own.
Report a bugSomething is missing
Tell me the moment on stage you are trying to fix rather than the feature you think you need — the fix is often a mapping that already exists.
Request a featureYou got it working
This is the most useful thing you can send. Which console, which firmware, what you mapped, and whether it survived a real gig.
Share a rig
All of this currently runs through GitHub, which suits engineers and makers and suits a working musician considerably less. A lower-friction channel for people who do not have a GitHub account is on the list — if that is you, it is a fair thing to complain about.
How to read this page
Nothing reaches “works today” on the strength of a plan. It moves when it runs on hardware. A few actions exist in the firmware’s schema and do nothing at all —midi.cc, midi.note, ws.send — and they are listed as not planned rather than quietly counted as features.
“Not planned” is an answer, not an oversight. Some of those items are only a no because nobody has needed them yet. If you need one, that is exactly the sort of thing worth telling me — a single real use case has already moved things across this board before.
Anything marked as missing elsewhere on this site links back here. Admitting a gap is only worth anything if there is somewhere showing whether it is being worked on.