[BUG]Send MIDI message to non-existense MIDI 1.0 device cable index port

[ShowUN00dles]

Describe the bug
When sending MIDI message to MIDI 1.0 device, Host PC sends non-existent cable index.

To Reproduce

1. Load the attached firmware to the ProtoZOA.
   This firmware has worked as MIDI 1.0 device, and this has 4 MIDI input/output as below.
   

2. Make sure the USB MIDI 2.0 driver (UsbMidi2.sys) is loaded.

3. Open midi.exe and send the enclosed midi message file which sends note on message to all GTBs.

4. Check the USB packet which outputs Host PC, and it shows Host PC sends all cable index even if the MIDI device has 4 ports.
   
   

Expected behavior
Host PC sends MIDI message to the exisiting MIDI port only.

Installer Name or Version

• Windows.MIDI.Services.In-Box.Service.-.1.0.1-preview.7.24305.1438-x64.exe

Desktop (please complete the following information):

• OS: Windows 11 24H2 build 26120.2415 (Insider Dev channel)

Device information, if this is with an external MIDI device:

• ProtoZOA running with the attached firmware.
  UUT_ZOA_104.zip
• USB MIDI 2.0 class driver (USBMIDI2_10.0.1.7.x64.zip)

Application Information
'midi.exe' console app.

Additional context
When we use MIDI 1.0 driver(USBAUDIO.sys), this issue doesn't happen. Host PC only sends first 4 MIDI I/O port as below.

[Psychlist1972]

Thanks. this is a known limitation in this release: all messages to/from WinMM use Group 0, which is going to map to that first port on a MIDI 1 device.

Duplicate of #418

[m-komo]

@Psychlist1972
This is the case using midi.exe (MIDI 2.0 API), not WinMM.
I think the main point of this feedback is that there is no cable number filter for USB MIDI 1.0 packets sent out by the USB MIDI 2.0 driver (USBMidi2.sys). As noted in the report, this issue has not been observed with the USB MIDI 1.0 driver (USBAUDIO.sys).

[Psychlist1972]

Oh got it. Thanks. I was reading another bug right before this and thought it was the same thing.

Our approach with the MIDI 2.0 driver with a MIDI 2.0 device is to send everything and the device drops messages when there's no existing group. Looks like the same logic is being used here @AmeNote-Michael , but that won't work. Instead, the driver needs to drop the message for the MIDI 1.0 device.

Changing to a driver bug.

[AmeNote-Michael]

@Psychlist1972 we need to discuss this. It would be a special data handling in the case of USB MIDI 1.0. In case of USB MIDI 2.0 the GTB and more importantly the Function Block information is unknown to the driver and thus the data-stream is just passed through in both directions - there is currently no handling for filtering data in the driver.

Should this filtering occur in driver? And then I would argue that there would need to be some kind of mechanism to handle for adapting filter in USB MIDI 2.0 as well.

[Psychlist1972]

@Psychlist1972 we need to discuss this. It would be a special data handling in the case of USB MIDI 1.0. In case of USB MIDI 2.0 the GTB and more importantly the Function Block information is unknown to the driver and thus the data-stream is just passed through in both directions - there is currently no handling for filtering data in the driver.

Should this filtering occur in driver? And then I would argue that there would need to be some kind of mechanism to handle for adapting filter in USB MIDI 2.0 as well.

MIDI 1.0 only. No changes to the MIDI 2.0 device behavior.

This would only be at the point where you actually go to send messages to a specific cable #. At that point, you're doing translation, and you're having to read the message to translate group->cable anyway.

[AmeNote-Michael]

@Psychlist197 this issue is resolved in PR#468