With the modified program run, I could confirm my endpoint is created properly:

 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
128:0    Zig UMP Endpoint                 MIDI 2.0
128:1    Zig UMP Endpoint                 Group 1 (My own UMP block)

With my daw pointing to the endpoint, I have sent the legacy midi event into my endpoint and I can confirmed that the old midi event are being converted to ump, and I could also recognize the note on and off packet. It even have translated into midi 2.0. I suspect the use of SND_UMP_EP_INFO_PROTO_MIDI2 does it, but I am not sure yet:

Packet:
01000000100100000011000000000000
11111111111111110000000000000000

Packet:
01000000100000000011000000000000
11111111111111110000000000000000

Packet:
01000000100100000011011100000000
11111111111111110000000000000000

Packet:
01000000100000000011011100000000
11111111111111110000000000000000

Besides, the ubuntu version also matter. Because I was using Ubuntu 24, the alsa and asoundlib was a few versions older which it didn't include the function for creating the ump endpoint and function blocks, ending with my header being outdated to the official documentation. Upgraded to Ubuntu 26 could access these missing functions.

Once again, thanks for your coding example! Otherwise, I might need much longer time to figure out how to receive my first umps.

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

The linked discussion rather concisely displays nearly every pro and con viewpoint possible about (1) should an octave designation be attached to the "note 60 equals middle C" specification and (2) if so there are at least two standards that define middle C, which standard should be used? 

What the much earlier thread does not touch upon is why the midi middle C standard needs the addition of an octave number.  The most reasonable reason I can give is the general population has a renewed interest in midi with the continual release of MIDI 2.0 standards.  Once again midi is exciting!  The best way to kill excitement is inconsistency.  Midi 2.0 has the opportunity to eliminate much of the inconsistency.  But how is that possible you may ask, it's a two step process.

Step 1 is to assign an octave value to middle C equals note 60.  Of course to assign an octave value the specification also has to state which standard the octave value is derived from.  That way there is a starting point for everyone to understand where middle C resides within an instrument's range.

Step 2 is during a midi device identity interrogation the midi device middle C octave value is returned.  Midi 1 hardware devices can be assigned a middle C octave value from either a look up table that will be compiled over time or by a one time user setting.

My understanding is MIDI specifications do not mention any octave number for middle C because there is not good agreement on which octave number to use. But my understanding is that MIDI specifications are otherwise clear that:

MIDI note number 60 is middle C.
MIDI note number 69 is A 440 hertz.
MIDI devices use 12-tone equal temperament by default unless other kinds of tuning messages change that.

I think it is well known that there is no universal agreement about what octave number to use for middle C. Anyone who is specifying pitches using pitch letters and octave numbers should explain what they consider middle C to be to avoid confusion. (Or provide the frequency of some note in hertz.)

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.

Windows 1.0.0 is officially available through the Microsoft Store, and Linux 1.0.1 is available as a verified Ubuntu/Kubuntu 24.04 .deb.

MIDI Manager is designed around local MIDI/KAR archive management rather than DAW project management. It indexes existing collections, extracts searchable technical information from MIDI files, and lets the user review analysis evidence before organization decisions are made.

The 1.0 release includes Search & Filter, Deep MIDI Analysis, analysis provenance, targeted reanalysis, safe copy-first organization, database-backed Organized Library browsing, playback workflows and FAT12/IMG image tools for vintage keyboard workflows.

The software does not require MIDI collections to be uploaded. Source folders remain under the user's control.

A real-world test collection containing 193,195 MIDI/KAR files has also been used throughout development to test large-library behavior.

More information and downloads:
https://musicnotehaven.ethercomm.eu/

I would be interested in feedback from people working with older hardware, unusually large MIDI archives or device-specific MIDI collections.

A small milestone for the project, but an important one: the Store version has passed certification, was installed directly from the public Microsoft Store on a Windows 11 test system, and retained the existing MIDI Manager settings and database correctly.

MIDI Manager is a local-first desktop application for people working with MIDI and KAR collections. It can index large collections, run deeper MIDI analysis, search and review files, detect MIDI/device characteristics, build a separate Organized Library, create playback queues, and prepare floppy/Gotek IMG files. Your MIDI files stay on your own computer or storage.

Windows 0.9.5 is now available directly from the Microsoft Store:
https://apps.microsoft.com/detail/9P9PKX8XNDWF

Linux 0.9.5-1 remains available as an Ubuntu/Kubuntu .deb.

Downloads and current release information:
https://musicnotehaven.ethercomm.eu/downloads/

I am still looking for MIDI users who want to test the application with real-world collections. That feedback is now directly influencing the work toward Windows 1.0.0 and Linux 1.0.1 — especially analysis explainability, preservation of MIDI data, Library Organizer usability and support for less straightforward MIDI/arranger-keyboard material.

The tester programme is here:
https://musicnotehaven.ethercomm.eu/midi-manager-testers/

I’m particularly interested in feedback from people with collections that go beyond straightforward General MIDI files: older archives, KAR files, keyboard/arranger material, GS/XG files, unusual controller/program/bank data, SysEx, and files that have survived several generations of software.

If anyone here tries it, I’d genuinely like to hear what it gets right, what it misunderstands, and what would make it more useful for serious MIDI collection management.