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
Increased number of encoder dial sensitivity setting levels #1275
Conversation
There is a test version in the #test-drive channel on Discord here, BTW: |
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.
Hi, I have tested that version from #test drive discord.
yes I fully agree with your comments , that new HIGH is also very good.
So now in this version , I like both NORMAL and the new HIGH .
(HiGHEST in my set is too sentitive , and for example difficult to select correctly the freq. steps from 100k , 1M , 10M , (easily it jumps from 100k to 10M ). But this effect is not appearing in the rest of lower levels : HIGH , NORMAL , LOW, LOWEST .
So I think that now , the user has more options to suit his encoder sensitivity needs.
Good job .
Increase number of setting levels for encoder dial sensitivity from 3 levels to 5 levels. This change only uses 30 extra bytes of ROM space, and adds intermediate levels between the original 3 levels, for finer tuning of the dial operation. Keep in mind that some PortaPack boards may be built with a 20-step encoder and some with a 30-step encoder, or users might have installed one that differs in the number of steps from the original, in which case the dial would need to be rotated a different number of degrees; adjusting this setting can compensate for that.
This PR changes the meaning of the sensitivity levels saved in Pmem, so you may want to adjust your encoder dial setting afterward upgrading or reset Pmem (I did not bump the version). For users coming from FW version 1.7.3 or earlier, Pmem will get reset to the default medium (2) sensitivity setting.
This PR does NOT resolve the worn encoder hardware issue described in #1273, so I've backed out part of the code change relating to that.