-
Notifications
You must be signed in to change notification settings - Fork 7.7k
fix(usbmidi): use channel in int16_t USB MIDI pitch bend #11795
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
fix(usbmidi): use channel in int16_t USB MIDI pitch bend #11795
Conversation
👋 Hello Skyslycer, we appreciate your contribution to this project! 📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more. 🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project. Click to see more instructions ...
Review and merge process you can expect ...
|
Memory usage test (comparing PR against master branch)The table below shows the summary of memory usage change (decrease - increase) in bytes and percentage for each target.
Click to expand the detailed deltas report [usage change in BYTES]
|
Test Results 76 files 76 suites 15m 7s ⏱️ Results for commit 0da3b04. ♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
Description of Change
This pull request fixes a small oversight in the USBMIDI pitch bend implementation:
There are three overloaded pitch bend functions for three different types of data: uint16_t, int16_t and double.
The actual implementation is located within the function accepting a uint16_t as the value parameter, while the other two simply convert the given data to match a uint16_t. However, the
channel
value, which should be passed along to the main function with the actual pitch bend implementation is ignored and unused in the int16_t function.Functions
I have confirmed this with the following minimal example on an ESP32 S3:
Probing this MIDI output with
aseqdump
shows, that the pitch bend values are being sent on channel 1 (the tool shows it as 0) instead of the specified channel 4:This pull request aims to fix this slight oversight.
Test Scenarios
I have tested my changes on both a LOLIN S3 Mini and a full size ESP32 S3, but I otherwise don't have any USB-native ESPs. The test consists of the same code above being ran. On both devices
aseqdump
displayed the correct channel 4 (the tool shows it as 3):Related links
I have just encountered this issue myself. I have not found an open issue matching this pull request.