[BUG]MME MIDI app receives wrong MIDI 1.0 message when sending MIDI 2.0 message.

[Sho-KDM]

Describe the bug
MME MIDI app receives wrong data when sending MIDI 2.0 data.
This was found by a compatible test of MIDI 2.0 message to MIDI 1.0 message conversion.

To Reproduce

1. Set the Roland UM-ONE mk2 to class-compliant mode (set the switch to "TAB") and short INPUPT and OUTPUT to loop back messages.
2. Attach the UM-ONE to PC.
3. Update the driver to the USB MIDI 2.0 driver (UsbMidi2.sys).
4. Open the Pocket MIDI 64bit and choose MidiSrv enumerated ports ("Roland UM-ONE I-1" and "Roland UM-ONE O-1") for Input.
   Input: Roland UM-ONE I-1
   
5. Click "Commands" menu button, and select "Write MIDI In data to log file...", and it shows logging file save dialogue. Select the save directory of logging file. After that, the data logging of MIDI in port starts.
   
6. Open midi.exe and send attached test data by "midi ep send-file" to UM-ONE.
7. All commands were recieved, click "Write MIDI In data to log file..." in "Commands" menu button. Then, stop the logging.

After that, we compare the logging file to the expected result data. Some of part are matched, but almost data is not matched. Especially, after receives "C0 00", app gets "C0 00" continuously about 20000 times.

For reference, enclosed file is our log.

Expected behavior
Pocket MIDI in log file shuold be matched the expected result data.

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.2222 (Insider Dev channel)

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

• Roland UM-ONE mk2
• USB MIDI 2.0 class driver (USBMIDI2_10.0.1.7.x64.zip)

Application Information
MORSON Pocket MIDI (64bit MME MIDI app)
https://www.morson.jp/pocketmidi-webpage/

Additional context
Same issue happened in different test data. For reference, I attached difference test data, expected result data, our log file as below.
Test data: TestUMP_MT4.txt
Expected result data: AnsMIDI_MT4.txt
Our log: MT4_roland_log.log

[MusicMaker]

FWIW. I have MIDIMAN Midisport 2x2 USB interface that does not loopback data correctly when connecting the IN A /OUT A via a DIN cable send data without any delays in between. When connecting A OUT to B-IN it works fine. A focusrite USB Autdio interface loops data back via DIN w/o any issues on on ports (perhaps it has a better implementation or a higher performance MPU/MCU), Sending MIDI via fast speeds USB and then loopback via a slow DIN on the same port using a cheap MCU interface may not be able to handle it well. Perhaps try another USB DIN interface ? A loopback test is a very good test to see if the interface design is well done or weak, but not sure that's an often used use case. :-)

[ShowUN00dles]

We observed this issue with MIDI 1.0 driver(USBAUDIO.sys) on MIDI service enumerated port.
Steps are as below:

1. Set the Roland UM-ONE mk2 to class-compliant mode (set the switch to "TAB") and short INPUPT and OUTPUT to loop back messages.
2. Attach the UM-ONE to PC.
3. NOT update the driver, keep MIDI 1.0 driver (USBAUDIO.sys) as below
   
   
4. Open the Pocket MIDI 64bit and choose MidiSrv enumerated ports ("Roland UM-ONE I-1" and "Roland UM-ONE O-1") for Input. In MIDI 1.0 driver, app shows both of MME port and MidiSrv enumrated ports, we could reproduce this issue on MidiSrv enumrated port, thus, we selected MidiSrv enumrated port.
   Input: Roland UM-ONE I-1
   
5. Click "Commands" menu button, and select "Write MIDI In data to log file...", and it shows logging file save dialogue. Select the save directory of logging file. After that, the data logging of MIDI in port starts.
6. Open midi.exe and send attached test data by "midi ep send-file" to UM-ONE(We changed the data set because this message is short and it's easy to check the USB packet).
7. All commands were recieved, click "Write MIDI In data to log file..." in "Commands" menu button. Then, stop the logging.

Compare result is below(Left side is observed data, and right side is expected data):

Also, we checked USB packet, and it shows MIDI messages are same as expected data as below.

It seems the wrong conversion caused after receiving the message, and regardless the driver.

[AmeNote-Michael]

This needs to be retested when known issue with service is resolved.

[Psychlist1972]

@ShowUN00dles please try this with the latest DP9 release. Thanks.

[m-komo]

@Psychlist1972
I tried this.
The issue persists with the DP9 NAMM Preview 2.
This can be reproduced with both MIDI 1.0 devices and MIDI 2.0 devices regardless of the driver.
Just receiving 2 bytes MIDI 1.0 messages, such as Program Change (C0 00) or Channel Pressure (D0 00) through the WinMM shim (wdmaud2.drv).
Lastly, the wdmaud2.drv causes an application error.
I have attached the event log (AppError_wdmaud2.evtx.zip).

[Psychlist1972]

@Psychlist1972 I tried this. The issue persists with the DP9 NAMM Preview 2. This can be reproduced with both MIDI 1.0 devices and MIDI 2.0 devices regardless of the driver. Just receiving 2 bytes MIDI 1.0 messages, such as Program Change (C0 00) or Channel Pressure (D0 00) through the WinMM shim (wdmaud2.drv). Lastly, the wdmaud2.drv causes an application error. I have attached the event log (AppError_wdmaud2.evtx.zip).

Ok. If it happens with any MIDI 1 or MIDI 2 driver, then this is a service / API issue. I will reclassify.

[Psychlist1972]

This has been fixed with the batch of updates related to #517

Result from running @ShowUN00dles test data file:

[Psychlist1972]

Fixed in Customer Preview 2 if you use the full GitHub Install on Canary 27802

[m-komo]

I confirmed the fix in the CP2 (x64-full installed). Thank you.