-
Notifications
You must be signed in to change notification settings - Fork 25
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] usbmidi 2 isn't handling message type 0xb correctly #356
Comments
@garydan42 @Psychlist1972 currently the action driver is supposed to take with reserved message types is to just drop data. However based on this bug report, it is suggested to pass along data anyways? Note, there is actually a bug in reserved message type sizes which needs to be resolved. |
I still need to test further, but I think driver is properly handling this. May be an issue with ProtoZOA load. Will continue to investigate and report. |
All messages which have a Message Type in the MIDI 2.0 UMP specification should be passed along, using the size indicated by the message type. Without that, no one would be able to prototype new messages on Windows. The service, API, and SDK all pass along messages, including reserved message types, without bias. As long as the message type matches the number of words, it's good. |
@garydan42 the driver was passing on USB OUT the packets properly, however on USB IN, reserved packets were being filtered. Removed filtering for next release. |
This issue is considered to be resolved and can be closed with next release. |
Describe the bug
usbmidi 2 isn't handling message type 0xb correctly, seems to treat the first part of the message as a 64 bit message, and discards it. Then it takes the remaining 32 bits and treats that as a new message, and interprets it based on that message type, creating a new message potentially larger than the data provided.
To Reproduce
run the midi.driver.unittests.dll test case TestCyclicUMPMidiIO, test case fails because an incorrect number of messages, 3 instead of 4, are received because the 96 bit message doesn't echo back.
Expected behavior
test should pass, 96 bit message should be echoed back.
The text was updated successfully, but these errors were encountered: