Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Twitter

Feature requests for CODE regarding encoder speeds

edited November -1 in Hardware
Hello Livid-

I really love my code. I haven't played out with it yet, but from general testing I can tell it will take center stage in my live setup. I do, however, have some feature requests regarding the speed of the encoders.

First, let's briefly discuss the inherent problem with "endless" encoders. The knob itself is optically scanned at some interval to determine which direction it turned and how far. But like the spokes on a wheel when filmed with a camera, if it moves too fast it is perceived to be moving in the opposite direction, or not at all.

With the code, I am pretty happy with its current implementation and the rate at which you are able to move the knobs, except for a few situations and nit-picky things. For example, the relation between the knob rotation and the encoder value is not 1:1, as in if you slowly rotate a knob and compare one of the notches to the LED ring, by the time a notch moves from "0 position" to "127 position" the encoder value LED is actually at about halfway, at 64 - this can give the subconscious effect that the knobs are moving slow. Therefore I do feel like there should be an extra layer of customization for the user. There are a few suggested solutions for this:

1. Allow each encoder to have a speed setting, able to be stored individually on a per-preset basis
2. Have a special mapping for a button to enable "fast rotation mode," so while the button is held down, the speed of the encoders is multiplied by some number. the larger livid button in the corner might be good for this
3. Mimic the way the machinedrum/monomachine does it, where pushing and turning a knob at the same time enables this "fast rotation mode." This would require the most amount of logic, as you would need to differentiate between a quick button push and a push-turn (you wouldn't want to send out the button press message if the user was doing a push-turn action). Since the use of pressing the knobs as buttons is one of the main features of the code, this way would probably be the most confusing for a user, so it is probably not the right thing to do here (although it would probably be natural for Elektron users)

As far as ease of use goes, #2 is definitely the simplest. And most of the time the most simple solution is the best.

Thoughts?

***
edit: I just did more testing of the knobs, and it does appear as though there is some variability on the speed based on the speed that the user turns the knob. In my example above I said that the value was moving at about half of the rate that I turned it, but it seems as though this is because I was turning it very slowly. If I move the knob more quickly, it gets closer to 1:1 movement. After this discovery, I have come up with a fourth solution:

4. Let the user configure the speed-interpolation curve that is used to scale the value based on the speed of the encoder, which already seems to be in place.
Sign In or Register to comment.