Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Problem
When a rotary encoder is spun, the resulting direction is immediately sent to the host machine. When this happens, the host machine will store a buffer of each spin (as there are typically many sent at the same time). The host machine then calls the volume changer logic on the operating system one instruction at a time. And since each instruction is equivalent to one rotation, multiple instructions need to be sent to the OS in order to perform the volume changes requested. The code to interface with the operating system is rather slow, meaning there can be quite a bit of latency between rotary encoder spins and the volume actually changing
Solution
The rotary encoder spins are now grouped into 200ms intervals. This allows for sending one request that represents multiple spins rather than multiple request with one spin. This reduces the latency seen with the OS operations
Additionally, the bitwise operations for determining direction of rotation were modified slightly. When using boards with different underlying storage space for
int
, the bitwise logic would not always act the way intended. For example, with the Arduino Unoint
representsint16
, whereasint
on a Teensy 3.2 is actually anint32
. This meant the bitwise math of the Teensy did not properly account for the negative rotation direction because the beginning 16 bits remained as all 0s. The datatype used to store was changed toint16
to allow for the math to continue to work regardless of board being used