Notifications
Clear all
Developers & MIDI 2.0 Specifications
2
Posts
2
Users
0
Reactions
7
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