MusicNote Haven

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.

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.