[BUG] SysEx Continue Message conversion issue

[sat-okada]

Describe the bug
If I send a 1byte/2bytes length System Exclusive Continue message in MT3 format, output wrong conversion results.

To Reproduce
1.Set the Roland UM-ONE mk2 to class-compliant mode and attach it to the UM-ONE to PC.
2.Driver uses UsbMidi2.
3.Start up two consoles, One is a monitor.

midi ep monitor --verbose

Send on the other

midi ep send 0x30160102 0x03040506
midi ep send 0x30210700 0x00000000
midi ep send 0x30210800 0x00000000
midi ep send 0x3022090A 0x00000000

4.Monitor receives wrong results.

Expected behavior
The following data should be received:
0x30120102 0x00000000
0x30230304 0x05000000
0x30230607 0x08000000

For the remaining 2 bytes (09, 0A), wait for the next SxsEx Continue message and get the first 1 byte to complete the SysEx Continue data.

Installer Name or Version
・Windows.MIDI.Services.In-Box.Service.-.1.0.1-preview.7.24305.1438-x64.exe
・Windows.MIDI.Services.Tools.and.SDKs.1.0.1-preview.7.24305.1438-x64.exe
・USB MIDI 2.0 class driver (USBMIDI2_10.0.1.7.x64.zip)

Desktop (please complete the following information):
・OS: Windows 11 Pro Insider Preview Build 27729.rs_prerelease.241011-1428

Device information, if this is with an external MIDI device:
Roland UM-ONE mk2

Application Information
midi.exe console app.

[MusicMaker]

I tested this case with my custom device in MIDI legacy mode. and used a monitor on my device that internally (not via DIN) loops incoming data back to the host. Though in my case I don't receive sysex data back on midi ep monitor unless changing the last command to END (3), which results in:

Index │ Message Timestamp │ From Last │ Words
──────────┼─────────────────────┼──────────────┼────────────────────────────────────
1 │ 5,070,167,234 │ 0.00 -- │ 31120102 00000000
2 │ 5,070,167,698 │ 2.49 ms │ 31230304 05000000
3 │ 5,070,167,729 │ 292.80 μs │ 31230607 07000000
4 │ 5,070,167,738 │ 73.20 μs │ 31230808 08000000
5 │ 5,070,167,746 │ 12.70 μs │ 31310800 00000000

It's different, but also incorrect. Then watching the data incoming on the device as attached video for reference.
This may help to get to the driver or service root cause. note there are 32 bits, as its the bytes of a USB packet + the packet type.
The problem is probably that the driver/service uses the byte count in the UMP packet incorrectly and/or assumes a continue is always 3 bytes and/or does not store it until it has 3 data bytes to send a CONTINUE or if less an END. Not to say this case may not really happen in real life, as a client should not send CONTINUE with less than 3 bytes.

USB.legacy.Sysex.continue.one.byte.case.webm

[AmeNote-Michael]

FYI, investigating this one. Am seeing strange behaviour in what I am requesting to send over USB versus what is captured on Beagle. Continuing to investigate.