Rotary encoder

[steved]

I'm integrating a rotary encoder (for front panel input) into ugfx, and wondering about how best to treat it.

The encoder has two out of phase inputs which can be decoded to generate clockwise and anti-clockwise (CW, CCW) movement events - typically 12 or 24 per revolution. It also (optionally) has a switch which is activated when the knob is pressed.

My initial thought is to treat these events as keypresses - Left/Right (or Up/Down) for CW/CCW, and Enter/Escape for knob pressed/released.

However I could also treat the events as specific flags (as is done with mouse clicks and the like).

The role of such an encoder is potentially context-dependent, so there could even be merit in keeping it outside the widget/window structure.

Any thoughts?

N.B. I looked using a dial implementation, but don't feel it's the right approach, since it constrains what you can do in response to the encoder events.

[inmarket]

Rotary encoders was one of things I was thinking about when designing dial.

In practice there are two models of use for rotary encoders

1. Like an analogue control eg a volume control. For this model a dial works perfectly.

2. As a direction encoder. For this the toggle interface is the best model with up and down toggles.

There is no reason that the driver for the rotary encoder cannot implement both driver interfaces at the same time allowing the user interface to pick which model it wants depending on the context of use. It may even use one model in one location and the other model somewhere else with the one rotary dial.

For the centre press a toggle is definitely the correct control.

[inmarket]

One more thought...

As a dial device it would be useful to be able to set the range of the dial. Changing the range would have the effect of changing the sensitivity. Eg a dial with a range of 0 to 30 would appear to reach full scale much faster than a dial of range 0 to 300.

Alternatively the increment could be changed to change the sensitvity rather than the range.

[steved]

Rotary encoders was one of things I was thinking about when designing dial.

In practice there are two models of use for rotary encoders

1. Like an analogue control eg a volume control. For this model a dial works perfectly.

2. As a direction encoder. For this the toggle interface is the best model with up and down toggles.

There is no reason that the driver for the rotary encoder cannot implement both driver interfaces at the same time allowing the user interface to pick which model it wants depending on the context of use. It may even use one model in one location and the other model somewhere else with the one rotary dial.

For the centre press a toggle is definitely the correct control.

Thanks for the suggestions - its certainly another way of looking at it. Presumably with option (2) one would just signal 'toggle on' events?

I've found mention of 'role' on some of the input devices, but it wasn't entirely clear what this meant. For a toggle, for example, are 'on' and 'off' simply separate roles? Or does it have a meaning which is separate from that of the state of the source?

I'm envisaging creating a display widget whose value increments and decrements with the dial, so the analogue representation isn't relevant to my requirements.

[inmarket]

Just "on" toggles - that makes sense. It would also be easier to implement than on with intermediate off's.

I can't remember the exact context of "role". I will examine the source and get back to you on that one. I think it might refer to when a slider for example can have two toggle inputs attached to it. One has the role of an up button and one has the role of a down button.

If you are talking about a rotary encoder incrementing or decrement in a counter - that is exactly what the dial interface is. An analogue dial is only one way to do that. In this case the rotary encoder is used to increment and decrement the counter "dial" value. The application gets notifications as the counter/dial value changes.

The current slider widget can be connected to a dial input now and it will do what you are suggesting. I don't think a progressbar has that dial input hook yet. A rotary equivalent to a slider widget would also make a great widget.

what defines a "dial" is something that can move in value between a minimum value (usually 0) and some maximum value. How that value is physically changed just depends on the driver eg analogue dial, rotary encoder, temperature sensor, possibly one axis of an accelerometer, a light sensor etc.

Digital or analogue doesn't matter.

[steved]

If you are talking about a rotary encoder incrementing or decrement in a counter - that is exactly what the dial interface is. An analogue dial is only one way to do that. In this case the rotary encoder is used to increment and decrement the counter "dial" value. The application gets notifications as the counter/dial value changes.

The encoder could be incrementing/decrementing all sorts of values, including list pointers, floating point values and the like. In most cases I wouldn't want any scaling to cause rounding errors.

[inmarket]

True - For list pointers, menu scrolling and that sort of thing the toggle model is best.