// Create an input port, but ump
const port_id = asound.snd_seq_create_simple_port(
    seq.?,
    "Zig Midi In Ump",
    asound.SND_SEQ_PORT_CAP_WRITE | asound.SND_SEQ_PORT_CAP_SUBS_WRITE,
    asound.SND_SEQ_PORT_TYPE_MIDI_GENERIC | asound.SND_SEQ_PORT_TYPE_APPLICATION | asound.SND_SEQ_PORT_TYPE_MIDI_UMP,
);

After that, I have created an async callback to receive the ump packet. is_active is a global variable so that the loop can be stopped outside the async function, while the type UmpEvent is snd_seq_ump_event_t: 

fn processUmpEvent(seq: ?*Seq) void {
    var ev: ?*UmpEvent = null;
    while (is_active) {
        if (asound.snd_seq_ump_event_input(seq.?, &ev) >= 0) {
            std.debug.print("Event type: {d}\n", .{ev.?.type});
        }
    }
}

While the program is run, since I also want to see how midi host that can't support ump behaves to my virtual input device, I decided to open a daw and trying to send something with it; unsurprisingly, although my daw recognized my virtual port, the port don't response to the event since my host didn't send ump event, but this creates some questions since I am not sure how should I handle this situation if I want to build a midi library or a midi host for example, so here are the questions:

- Is the behavior of legacy midi host recognized my virtual input device intended?
- When I build a virtual input device, do I need to check if the new incoming or target device support ump? Or my virtual device should always handle both ump and legacy format? Or I should prevent the legacy device to connect to the ump endpoint?

Please let me know if anyone needs more info for the questions, or if the question is duplicated so that I could referred to the existing discussion.

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:

1. 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.

2. 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 full vs partial update flow and how different peers handle it.

3. 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.

Is there somewhere I'm missing on the forum or main TMA webpage that has a list of the current and past working groups? And possibly WGs being considered for the future for review or display of interest? Or maybe these are by invitation only? 

Thank you

As I understand it, there is a possible race condition around the initial baseline state.

For example:

1. The Initiator performs Get and obtains the current full state of a resource.
2. The Responder’s resource changes after that Get response.
3. The Initiator sends Subscription Start.
4. The Responder accepts the subscription and then starts sending Subscription Partial updates for subsequent changes.

In this sequence, the change that happened between the initial Get and the Subscription Start may not be observed by the Initiator, unless the Initiator performs another Get after Subscription Start to establish a reliable baseline.

From an interoperability point of view, it seems safest if Initiators are recommended to perform Get after Subscription Start has been accepted, and then apply subsequent Subscription Partial updates on top of that state.

Is there any plan to clarify this in the specification or implementation guidelines?

If this behavior is not recommended or required for Initiators, then as a conservative Responder implementation, I may need to send Subscription Notify immediately after accepting Subscription Start, in order to prompt the Initiator to retrieve the current full state.

However, if both sides behave conservatively, this can result in redundant Gets:

• The Initiator sends Get after Subscription Start to establish the baseline.
• The Responder also sends Subscription Notify after Subscription Start to prompt a Get.
• The Initiator may then perform an additional Get because of the Notify.

This is not necessarily incorrect, but it seems inefficient and could lead to inconsistent implementation patterns between devices.

So my questions are:

1. Is the intended/recommended behavior that an Initiator should perform Get after Subscription Start has been accepted, in order to establish a reliable initial baseline?
2. If so, would it be appropriate to clarify this as a recommended practice in the specification or implementation guidelines?
3. If not, what is the recommended Responder behavior to avoid missed changes around Subscription Start?
4. Should a Responder send Subscription Notify immediately after accepting Subscription Start, or should it avoid doing so to prevent redundant Gets?

My main concern is ensuring that the Initiator and Responder can share a complete and correct resource image without relying on implementation-specific assumptions.

It's been a few months since I started working hard on implementing USB MIDI 2.0 on embedded systems. My starting points were Andrew Mee's AM_MIDI2.0Lib (MIDI 2.0 protocol), AmeNote's tusb_ump, and Mike Kent's ProtoZOA (embedded and USB), along with the official specs. My interest in this topic came from work I've been doing for a few years on MIDI transports for ESP32 (<a href=" removed link " target="_blank" rel="noopener noreferrer">ESP32_Host_MIDI). Along that path, I've been learning a bit about embedded architecture and the transport layer, especially USB.

It took many weeks of testing against Linux and Windows hosts, reading through M2-104-UM and the USB MIDI 2.0 Class Definition paragraph by paragraph. Last month I reached a stable version using TinyUSB, both Device and Host modes, validated first on RP2040 and then on Adafruit Feather RP2040 Host (Pico SDK, CMake). After testing across several devices, I opened the upstream PR: <a href=" removed link " target="_blank" rel="noopener noreferrer"> removed link .

Since then, I've been running a local branch based on the PR to keep the work moving. And that's the reason for this post: to see if others are on the same path and find allies here in the forum to push embedded MIDI 2.0 forward. So far, on my bench, I've enumerated on RP2040, RP2350, ESP32, Nordic nRF52840, and SAMD21. All of them enumerated cleanly on both Windows MIDI Services and Linux.

One angle in particular has been getting special attention: Teensy, Daisy Seed, and ESP32-P4. These are hacker-friendly boards with real audio processing capability. The experiments on these three are well under way, and this axis, where MIDI 2.0 meets real embedded audio, is where I'm going deeper.

It's been a really good experience. I'm excited about where this is going, and it would be great to find others walking a similar path.