Issue: Provide Visual and/or audio feedback of encoder press events

[wyleu]

Describe the issue

If the GUI interface is used, selecting between the three modes of an encoder press would benefit from feedback to confrim both the initial press being received and the thresholds for short, bold and long differentiated.

Configuration

Hardware

Raspberry Pi 4 Model B Rev 1.4
Audio: Behringer UMC1820
Display: Pi 7 Touchscreen Display 800x480
Wiring: MCP23017_EXTRA
I2C: MCP23017@0x20
Profile: v4_studio

System

Debian GNU/Linux 12 (bookworm)
Build Date: 2024-05-21
Memory: 12% (975M/7809M)
Internal Storage: 61% (17G/29G)
Temperature: 61.8ºC
Overclock: None

MIDI & UI

Tuning: 440 Hz
Master Channel: Off
Preload Presets: On
ZS3 (SubSnapShots): On
Power Save: 60 minutes
Audio Levels on Snapshots: On

Software

zyncoder: vangelis (092fb26) 
zynthian-ui: vangelis (add0179)
zynthian-sys: vangelis (4b568b8)
zynthian-data: oram (bee88d0)
zynthian-webconf: vangelis (4dab315)

[riban-bw]

This has been discussed extensively in this forum post.

Do we want it? It does provide some useful feedack to the user so, if it can be implemented without excessive impact (e.g. to performance, overal UX, etc.) then I would be happy to see it.

How should it present? I think an indication of short and bold press would be sufficient. Show nothing if nothing is pressed (obvs!). Long actions are triggered before releasing button so the action should be evident to the user and does not require further visual indication, so long press should clear or reset the indication. So, a 2-state indication to represent short and bold should be sufficient. This could be concentric circles, two bars, a letter (S/B), etc. This level of presentation can be chosen later.

Where to show? Maybe in the topbar? This is a fleeting display so may not impact topbar occupancy excessively. We could use the health / update icon space if we are concerned with space.

How many? There are 25 switches on the V5 and many users have 10 fingers so there could be several concurrent switches being held. It may be impractical to support the parallel indication of multiple switches. Maybe we should have a single indication that is a summary of all buttons, e.g. the short press indication is shown if any switch is in its short phase, etc.

What impact might there be to system resources? This will add some overhead for detecting, processing and displaying states. Most notably, the detection of short to bold transition is not currently done. Short and bold press are detected on the switch release by calculating the press and release time delta. The long press is detected by a timer. There may be capacity to expand the long press detection to also detect bold. I believe this is likely the most important aspect of this request. There will also be some overhead in displaying the status as each draw/redraw will consume some resources. Screens are generally refreshed on a timer at a relatively slow rate (I think it is 30ms) so there may be some error in display but probably sufficiently small to avoid confusion. We are really just looking for the transition from short to bold and there is (by default) a long time between bold and long for the display to update reliably.

What triggers this? We have only really considered physical button presses so far but there are also keybinding, MIDI binding, OSC binding, touchscreen, etc. These should all behave in a similar or expected manner. Also there may need consideration of context, e.g. some button detection may be different under differenct conditions or different places in the UI / workflow.

I would like to hear what @jofemodo thinks about this.

[riban-bw]

See? Ask nicely and things happen... I have created dev branch 1346/indicate_bold which adds an indication of bold press. This is currently just a "B" replacing the health status indication but could be enhanced. I did implement "S" for short but realised this isn't really of much use. A user who presses a button kinda should know that they have pressed the button. If they release it and nothing happens then they will press it again, properly. So indication of the short press period gives insignificant benefit.

Processing of this is done in the CUIA thread in the same way as the procesing of long press. I don't think it adds much load.

[wyleu]

This would seem to be another flag to throw in admin, but I would suggest the addition of a debug mode that allows encoder & CUIA interface actions to be reported in a prescribed way to allow testing. Not so much for Official kits which are, obviously, the canonical reference, but for the un-official home built devices to confirm operation of hardware interface configuration and operation.

That should reduce the thread debates on getting specific devices operational as we have an easily acknowledged event confirmation.

[riban-bw]

I don't think this warrants an enable flag. It is either useful or not. If useful it should be non-intrusive. I think it can be implemented without causing anyone problems. Whether that be an icon in the topbar or maybe a border that shows is detail and can be changed or enhanced in time. We all like a bit of eye candy change in new releases.

[riban-bw]

Updated to use a downward, end-stopped arrow which may be a little more intutive. This is not yet working for touch though so I will have a look at that...

[wyleu]

Audio feedback?

This would seem to be a fundamental aspect of operation without visual facilities, whether this is a talkback only in ear facility for example.

[riban-bw]

Regarding touch - this is proving challenging. I tried to invert the touch element colours to give the indication but this doesn't work on all controls (some odd bug that I can't trace) and doesn't scale well.

Regarding sound - this has the same argument as the visual feedback. If a user learns to use the controls then they can do so blind. Knowing that you have pressed a button for 1s is either a mental ability or has some feedback. Any such feedback is equally valid as visual or sound. Accessibility is another subject, not directly related to this topic.

There has been engagement from the community on this topic and there seems to be a consensus that feedback of bold press is not required and may in fact be disconcerning or distracting.

So, despite having implemented the feedback for switch (in dev), I will reject this request. Sorry that you feel so strongly on this subject but it has been given substantial consideration and the decision is that there is minimal benefit and significant risk of increasing support (which ironically is the opposite of the feature's intended purpose!).