Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Sho-KDM opened this issue Nov 14, 2024 · 2 comments
Assignees
Labels
area-service-or-api 🖥️ Related to the Windows Service, core API, abstractions, etc. area-usb-driver 💻 Related to the USB MIDI 2.0 driver bug 🐞 Something isn't working needs-investigation 🔍 Needs to be investigated before considering or solving.

Comments

@Sho-KDM
Copy link

Sho-KDM commented Nov 14, 2024

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
    Image
  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.
    Image
  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.
Image
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

@Sho-KDM Sho-KDM added the bug 🐞 Something isn't working label Nov 14, 2024
@MusicMaker
Copy link

MusicMaker commented Nov 14, 2024

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. :-)

@Psychlist1972 Psychlist1972 added area-service-or-api 🖥️ Related to the Windows Service, core API, abstractions, etc. needs-investigation 🔍 Needs to be investigated before considering or solving. area-usb-driver 💻 Related to the USB MIDI 2.0 driver labels Nov 14, 2024
@ShowUN00dles
Copy link

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
    Image
    Image
  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
    Image
  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):
Image

Also, we checked USB packet, and it shows MIDI messages are same as expected data as below.
Image
It seems the wrong conversion caused after receiving the message, and regardless the driver.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-service-or-api 🖥️ Related to the Windows Service, core API, abstractions, etc. area-usb-driver 💻 Related to the USB MIDI 2.0 driver bug 🐞 Something isn't working needs-investigation 🔍 Needs to be investigated before considering or solving.
Projects
Status: No status
Development

No branches or pull requests

5 participants