Notifications
Clear all
Developers & MIDI 2.0 Specifications
5
Posts
3
Users
0
Reactions
351
Views
Topic starter
I wanted to share a proof-of-concept and open a discussion, because I think it says something useful about where Property Exchange is right now.
What I built. A small PE responder (running on a Mac) that impersonates a sound generator. It serves resources built from data that a synth already has — its parameter names and its CC map — so that a hardware controller can discover it over MIDI-CI. The result: the controller auto-labels its eight knobs with the synth's real parameter names and drives them, with no MIDI-learn and no templates. The two products were never designed to interoperate; PE made them.
For me this was the "oh, it actually works" moment — the thing PE promised, running on real gear. It scaled cleanly across ~47 instruments from one software collection.
Why I'm posting. Getting there took more reverse-engineering than I expected, and I ran into a few things I'd genuinely like other implementers' perspectives on:
-
Standard vs. vendor-specific resources. The controller I used fetches vendor-specific
parameter/value resources rather than the standardized
CtrlList/AllCtrlList. Is that common in the wild? Has anyone successfully served standard controller resources to a shipping controller and had it map knobs from them? I'd love to know how portable a "standard-resources-only" responder actually is today. -
Subscriptions / value sync. For a responder to advertise live values and have a controller
display them, what's the subscription behavior you've found works reliably? I'd like to compare notes on the
fullvspartialupdate flow and how different peers handle it. -
Robustness patterns. Stale MIDI-CI sessions, re-subscription behavior, MUID invalidation on
reconnect — is there an agreed set of best practices or, ideally, a reference implementation people build against?
Offer. I'm happy to share the responder and the harvester (the bit that turns a synth's shipped files into a PE resource set) as a reference — it might save the next person the reverse-engineering, and it could be a useful starting point for anyone building a responder. If there's interest in an open reference implementation / conformance-style test set for PE, I'd gladly contribute what I have.
Mostly I'd love to hear from anyone else implementing PE — what's worked, what's been painful, and whether the standard-resource path is as viable as I hope it becomes.
Posted : 06/08/2026 3:26 pm
Hey this sounds like great work! It would be great to see this as an open source project on Github (or similar).
As to your questions:
> Standard vs. vendor-specific resources. The controller I used fetches vendor-specific
I am assuming you're referring to Korg's implementation. Korg did that implementation before MA released the Controller PE messages.
I have served standard CtrlList / AllCtrlList on protoypes, and I know that some companies are looking at this more.
> Subscriptions / value sync. For a responder to advertise live values and have a controller
So the suggested method for Channel Voice Message values (as opposed to other types of values) is to use Process Inquiry to retrieve a snapshot and them work with the CVMs as they are sent from the device.
Moving onto doing values over PE the subscription mechanism is depending on the data. For simple small data I recommend sticking to a full/notify update. For data that is a bit more structured then partial on a small change, and notify on a large change
> Robustness patterns. Stale MIDI-CI sessions, re-subscription behavior, MUID invalidation on reconnect
Not 100% I understand specifically the question. But on a MUID invalidation I generally throw away all information (including cache) and start again.
Posted : 06/08/2026 6:13 pm
Topic starter
Following up — I tried the notify approach you suggested, and it worked. Quick report in case the data's useful.
I'd been pushing updated values directly before (both full and partial); the controller replied status 200 but never repainted. Switching to the notify flow — update my copy of the value resource, then send a notify — got it to re-GET the resource, and the displayed value now updates. So the notify was the missing piece. Thank you.
One nuance, in case it's expected behavior on your end: it doesn't repaint live while you're on the parameter page — the value refreshes when you navigate back to that page, as if the controller re-reads on page-enter rather than continuously. Not real-time, but no longer frozen. Is that what you'd expect, or is there a trigger I'm missing to force a repaint of the currently-displayed page?
Context that colors this: the sound generator I'm bridging to doesn't speak MIDI-CI at all, so the values I'm serving are really the last value the controller's own knob sent, reflected back — not the instrument's true state. So this is "show the knob's own position," which is the ceiling until the synth itself participates. Your Process Inquiry pointer is noted for when there is a device to ask.
Also — thank you for the note that the controller's proprietary resources predate the MA Controller PE messages. That reframed it for me from "fragmentation" to "legacy the standard has since caught up with," and it's great to hear you've served standard CtrlList / AllCtrlList on prototypes.
I'll get the project up on GitHub and post the link here — would genuinely value your eyes on it.
Posted : 06/08/2026 8:49 pm
One nuance, in case it's expected behavior on your end: it doesn't repaint live while you're on the parameter page — the value refreshes when you navigate back to that page, as if the controller re-reads on page-enter rather than continuously. Not real-time, but no longer frozen. Is that what you'd expect, or is there a trigger I'm missing to force a repaint of the currently-displayed page?
Is this on the workbench - or some other software - sorry not sure what you're referring to here?
Posted : 09/08/2026 5:25 pm
Hi Nick,
On question 3, a trap that cost me some time and might be useful: the MUID being generated before the RNG is seeded. On the RP2350 I had a fixed MUID on every boot, and nothing breaks until there are two identical devices on the same bus, then both declare the same MUID and the session becomes ambiguous. It only showed up when I went to check the MUID on the wire rather than in the log.
On your offer of an open reference: there's interest on this end. I work from the opposite side to yours, with the responder running inside the device, on the MCU, not on the host. I've run that successfully against the MIDI 2.0 Workbench on several MCU families.
😉
Posted : 19/08/2026 2:47 pm