Hello @hathach, @HiFiPhile,
Hope you're both doing well. The MIDI 2.0 host from #3571 opened up something neat, and I wanted to run an idea by you before sending a PR.
Context
The host stack now has two separate MIDI drivers: the legacy MIDI 1.0 driver (CFG_TUH_MIDI) and the MIDI 2.0/UMP driver (CFG_TUH_MIDI2). Enabling both in the same build conflicts, since both try to claim the same MIDIStreaming interface when a device is plugged in.
What I'd like to propose
A small change (in midi2_host.c, midi_host.c, midi2_host.h) that lets the two coexist. When claiming a device, each driver does an "alt-walk" over the bcdMSC of the MIDIStreaming interface alt settings: if any alt advertises bcdMSC major >= 0x02, the device is MIDI 2.0 and the legacy driver defers; otherwise the 2.0 driver defers and the legacy one takes it. The block in the legacy driver sits behind #if CFG_TUH_MIDI2, so legacy-only builds stay byte-identical.
Why it matters
It lets a single host accept MIDI 1.0 and MIDI 2.0 instruments at the same time, without recompiling. I built an ESP32-P4 bridge that does exactly this: on the USB-A ports, a MIDI 1.0 controller (Arturia) and MIDI 2.0 devices (Teensy, Daisy Seed, RP2040) each enumerate through the right driver and play simultaneously, forwarded to the PC. As far as we can tell, this is the first host/bridge running USB-MIDI 1.0 and 2.0 side by side, sounding at the same time.
Question
Would you be open to a PR with this approach (routing by bcdMSC with the legacy driver deferring)? Since it touches the legacy driver, I wanted to confirm the design before opening it. I can send the PR with the full diff and build results once I have your OK.
Hello @hathach, @HiFiPhile,
Hope you're both doing well. The MIDI 2.0 host from #3571 opened up something neat, and I wanted to run an idea by you before sending a PR.
Context
The host stack now has two separate MIDI drivers: the legacy MIDI 1.0 driver (
CFG_TUH_MIDI) and the MIDI 2.0/UMP driver (CFG_TUH_MIDI2). Enabling both in the same build conflicts, since both try to claim the same MIDIStreaming interface when a device is plugged in.What I'd like to propose
A small change (in
midi2_host.c,midi_host.c,midi2_host.h) that lets the two coexist. When claiming a device, each driver does an "alt-walk" over thebcdMSCof the MIDIStreaming interface alt settings: if any alt advertisesbcdMSCmajor >= 0x02, the device is MIDI 2.0 and the legacy driver defers; otherwise the 2.0 driver defers and the legacy one takes it. The block in the legacy driver sits behind#if CFG_TUH_MIDI2, so legacy-only builds stay byte-identical.Why it matters
It lets a single host accept MIDI 1.0 and MIDI 2.0 instruments at the same time, without recompiling. I built an ESP32-P4 bridge that does exactly this: on the USB-A ports, a MIDI 1.0 controller (Arturia) and MIDI 2.0 devices (Teensy, Daisy Seed, RP2040) each enumerate through the right driver and play simultaneously, forwarded to the PC. As far as we can tell, this is the first host/bridge running USB-MIDI 1.0 and 2.0 side by side, sounding at the same time.
Question
Would you be open to a PR with this approach (routing by
bcdMSCwith the legacy driver deferring)? Since it touches the legacy driver, I wanted to confirm the design before opening it. I can send the PR with the full diff and build results once I have your OK.