[Question] How to Handle Ump Virtual Input with Midi Devices Only Supporting Legacy Midi

[GitHub issues - edited <github@alsa-project.org>]

alsa-project/alsa-lib issue #520 was edited from Logickin-Lambda:

Hello everyone, thank all of you bringing midi 2.0 support into alsa. I have managed to create a simple legacy midi virtual device so that I can send and receive midi from/to the music making software I used (I used SunVox for the experiment); however, while I am messing around the new ump format, I have faced an issue where Legacy Midi device have no awareness to know if the target endpoint uses ump or not, ending with the input callback receive nothing.

The code example is the following. Despite written in zig, all the functions and enums remain identical to the C code:
``` zig
fn createUmpInput(init: std.process.Init) !void {
    var seq: ?*Seq = null;
    const ret = asound.snd_seq_open(&seq, "default", asound.SND_SEQ_OPEN_DUPLEX, 0);
    if (ret < 0) @panic(try std.fmt.allocPrint(init.gpa, "Failed To Open Alsa Midi Sequencer, Error: {d}\n", .{ret}));

    defer std.debug.print("\nseq closed, status: {d}\n", .{asound.snd_seq_close(seq)});

    var buf: [8]u8 = undefined;
    var reader = std.Io.File.stdin().reader(init.io, &buf);
    const interface = &reader.interface;

    // Create an input port, but ump
    const port_id = asound.snd_seq_create_simple_port(
        seq.?,
        "Zig Midi In",
        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,
    );

    var future = init.io.async(processUmpEvent, .{seq});
    _ = try interface.takeByte();
    is_active = false;
    future.await(init.io);

    std.debug.print("Created input port: {d}\n", .{port_id});
}

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});
        }
    }
}
```

When I open SunVox, although it doesn't support ump, it somehow recognize the `Zig Midi In` device where I "can" send the midi output to the ump endpoint; unsurprisingly, it doesn't work, but this creates a question:

If I have created a virtual input device that is expected to receive ump, while my midi device can only support legacy midi events, what is the common practice to implement a fallback mechanism for the legacy midi device? Or is the virtual device simply ignore the incoming legacy midi format?

I have checked the [documentation](https://www.alsa-project.org/alsa-doc/alsa-lib/seq.html#seq_midi2), but besides:


> In either UMP mode, we use [snd_seq_ump_event_t](https://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__ump__event__t.html) for sequencer event records instead of [snd_seq_event_t](https://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__event__t.html) due to the lack of the data payload size in the latter type.

And 

>For creating a UMP Endpoint in an application, call [snd_seq_create_ump_endpoint()](https://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#gae4d6661744be758c5ecd7d0352e90665) with a properly filled [snd_ump_endpoint_info](https://www.alsa-project.org/alsa-doc/alsa-lib/group___raw_midi.html#ga1e37d1b7281227949fe7716f3f129482) data.

I don't seem to find any info regarding how to handle legacy midi device attempting to connect a ump endpoint. Am I missing something? Let me know if further info is needed.

Besides, could anyone suggest any linux midi software that supports the ump format for testing, besides [MIDI2.0Workbench](https://github.com/midi2-dev/MIDI2.0Workbench) since I don't want to install a very specific version of node.js and `yarn` that I have no other application with it?

Issue URL     : https://github.com/alsa-project/alsa-lib/issues/520
Repository URL: https://github.com/alsa-project/alsa-lib