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

Is assigning a pitch value such as C2, C3, C4 or C5 to midi middle C equals note 60 under consideration?

As things currently stand there is hardware and software that use each of the pitch values listed above as their middle C standard.

Whatever audio is played back may not represent the intent of the midi composer because the audio maybe played back at the wrong octave.

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.

I’m a hobbyist developer and music gear enthusiast, and I wanted to share a small project I’ve been working on called Lumidi.

The idea started from something pretty simple: I have MIDI controllers sitting on my desk, and when I’m not using them they’re basically just grids of unlit LEDs.

So I thought… why not make them do something? 🙂

Lumidi is a small Windows app that detects when a supported MIDI controller is idle and turns its LEDs into animated light displays. When you start using the controller again, Lumidi gets out of the way.

It currently includes 30+ animated themes, with controls for things like animation speed and brightness.

I’ve physically tested it with:

• Novation Launchpad Mini MK3
• Novation Launch Control XL 3

There is also beta support for other Launchpad models, and I’m gradually looking at expanding device support.

I’ve tried to keep Lumidi simple: it runs in the background and brings a bit of life to MIDI controllers when they would otherwise just be sitting idle.

Lumidi is currently available for Windows through the Microsoft Store.

As this is still a new project and I’d really like to get it into the hands of more MIDI controller users, the first 1,000 downloads can get Lumidi for free from the Microsoft Store with this code:

42CGJ-X3243-CR97X-MG9M6-6X33Z

I’d be genuinely interested to hear what people who use MIDI controllers every day think about the idea — particularly which controllers you think would be worth supporting next.

Feedback, bug reports and technical questions are all very welcome.

Thanks for taking a look!

My name is Joël and I work with computer music for 20 years. I started with Gtk+-2.0 for UI as it was released around 2002 and did my first programming experience with ANSI C99. Most coding was done on an intel based notebook running debian unstable.

Since hacking is a time expensive task, I enjoy creating music by importing SMF to my sequencer software.

removed link

A future goal would be to make more music and less programming.

So can you recommend any websites for SMF download?

----

regards, Joël

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