Use with Rotary Encoder?

[polygonfuture]

Hi there,

Trying to find examples of using GEM using a single push-button rotary encoder. Do you have any examples of this?

Cheers

[Spirik]

Hi=)

Unfortunately there is no example for rotary encoders specifically, but theoretically as soon as input device can produce 6 basic operations that menu understands (up, right, down, left, ok, cancel) it should be completely possible. But it is up to you to figure out how to extract those readings from encoder (or any other input device for that matter).

See Control menu from your sketch section of wiki for a little more details. You may want to look into how KeyDetector or U8g2 key detection organized in supplied examples (in their loop()) as a starting point.

Hopefully this may help!

[polygonfuture]

@Spirik Thanks for a quick reply!

Ah ok I think i understand now. So the "control menu from sketch" literally lets you control a menu arbitrarily with whatever conditional or changes you want.

One followup: Is there a straight forward way to change the logic for how the menu item / selection process works?

For instance I specifically want to change the way the digit selection process works. Preferably in this way:

1. Select a menu item
2. Left or right key press will change the digit selection position.
3. A push button will select for edit
4. Left or right key press will change value up or down.
5. Push button again will "set" digit and let you continue to move left or right from digits.

I would still have a dedicated back or cancel button. This would allow me with a rotary encoder + extra push button to control all menu settings.

[Spirik]

How an item would be saved in that scheme (apart from pressing cancel button, which results in exit without saving), since you're planning to use push button to select digit position while in edit mode? Or is your plan to save an item any time its digit is saved? That may lead to some unwanted results (unnecessary triggering validation callbacks, redrawing menu, etc.).

And I am afraid there is no way you can edit this logic without editing source code of library.

What you can do without modifying the source code, however, is to wait for menu to be ready to accept a key press and then fire up your own logic to determine which menu key press to trigger:

void loop() {
  // If menu is ready to accept button press...
  if (menu.readyForKey()) {
    // ...detect key press using your own logic
    byte keyCode = myRotaryEncoderKeyDetectionLogic();
    // Pass pressed button to menu
    menu.registerKeyPress(keyCode);
  }
}

Edit:

On the second thought, It still may be possible to recreate the logic you described without editing the source code. Just track combination of short and long presses of the push button to determine how to interpret the rotation of the knob (whether to send GEM_KEY_LEFT/RIGHT or GEM_KEY_UP/DOWN codes).

[polygonfuture]

Well the encoder has a push button built in. So I would have two push buttons total, and two left/right keys (encoder).

This sounds promising. I'll take a stab at this in the morning.

Another question: How does one constrain the values while editing?
For instance lets say I have a value of 3523 and I want to limit its settings from 3000 - 3800. Is there a way to handle constraining this value?

Also related, is there possibly a way to instead of editing digit by digit, you could simply +/- from the full value all together?

[Spirik]

Another question: How does one constrain the values while editing?
For instance lets say I have a value of 3523 and I want to limit its settings from 3000 - 3800. Is there a way to handle constraining this value?

You can not constrain user input during edit mode, however you can implement validation callback, that will be triggered upon saving the value: that way you can change value to, say, the closest one from the valid range, once user finished editing.

Also related, is there possibly a way to instead of editing digit by digit, you could simply +/- from the full value all together?

Nope, unfortunately there is no way to do that at the moment. However there is possibility it will be implemented in the future via dedicated menu item type.

[danieltwagner]

In case this is relevant, I'm after similar functionality and among other things #42 adds a callback upon entering the edit mode. You could use that to start scrolling over the desired range.

[Spirik]

@danieltwagner Does your implementation allow to scroll over an entire range of a number, or just a single digit of that number?

[danieltwagner]

Just the single digits as is the case in "vanilla" GEM. I was going to look at extending it to scroll over the entire range though. It just turned out to not be super straight-forward to figure out an intuitive interaction to cater to both long ranges as well as fine adjustments so I've punted that for now to implement the part that the controller/menu actually controls :)

[zandernc]

I implemented this as you suggested, Spirik, assigning the encoder to up/down keypresses, and a short press of the button to "ok" and a long press to "right". Works great. Thank you!

[Spirik]

@zandernc Is it possible to rotate the knob while simultaneously being pressed on your encoder? If it is, then I would suggest to consider the following scheme:

• Rotation - Up, Down;
• Rotation + Press - Left, Right;
• Short press - Ok;
• Long press - Cancel.

That way we will cover all 6 interactions GEM is able to respond to.

[Spirik]

👋 FYI: just updated GEM with examples on how to control menu with rotary encoder using latest version of KeyDetector (implementing control scheme described above).