Contour Shuttle (Surface): Add repeating button-presses in response to the shuttle ring

[arikorn]

Add repeating button-presses in response to the shuttle ring, to enable "shuttling" (i.e. fast-forward/reverse type of actions).

Resolves issue #3491 Please see the issue for more details.

[Julusian]

I'm not keen on adding click events to this as well as the rotate events. That feels weird to me..

I'm not sure what I would prefer though.
I don't entirely like how this surface emits any rotate events, I would prefer it to do just the variable. Replicating this pr could be done with a pair of triggers off that variable, except that the current interval trigger event only runs to whole seconds.

[arikorn]

@Julusian , would you accept the PR if I removed rotation events on shuttle altogether? I certainly don't need or want them -- I just left it in for compatibility. (Personally, requiring someone to add triggers, or do as I outlined in the issue, seems like a less desirable solution than this PR.)

FWIW, the manufacturer's "control panel" app does allow defining actions for "Transition from Left 3 to 2" and so on, as well as for "Shuttle in Left 2" which could be considered another justification for allowing both rotational and press actions (i.e. the manufacture themselves supports it). But again, my preference is for repeated presses, which seems the most natural way to define things. In fact, the manufacturer's control panel uses repeated button-presses as its main way of handling the shuttle.

[arikorn]

added commit: Modified code to allow 'click' event to set the "force" argument in the controls.pressControl() method

[arikorn]

In thinking about "appropriate use" of the shuttle, I "surveyed" Countour Design's prepackaged configurations for the shuttle ring. Of 140 profiles specified for the Contour Shuttle (v1):

• 6% react to transitions (i.e. differentiate between shuttle rotate-right and rotate-left)
• 19% specify a single keypress for each position, i.e. don't care about rotation direction and don't need repeats
• 75% specify repeated keypress or mouse actions for each position, i.e. don't care about rotation but do repeat at variable rates

(Examples of single-keypress include software in which each keypress increases the playback speed or where there's a different F-key for each speed.)

Now to be fair, these are all for software control on the local computer and the actions are limited to keypress or mouse action, so for example, my main use-case -- to change the value of a parameter directly and have the magnitude of change vary by shuttle position -- is not even considered. I concede, however, that my situation can be handled by variable-rate repeated actions.

My take-aways:

1. Since 75% of the situations used variable-rate repeated actions, that seems large enough to justify adding repeated actions as suggested in this PR.
2. Nevertheless, 25% is substantial enough that both options should be made available to the end-user.

One simple way to allow both options is to provide non-repeating rotational actions and a repeating "press" action, as done in this PR. The user can then choose the appropriate behavior by whether they put their actions in rotational vs. press scripts.

If you agree I can update this PR to:

• A. provide variable-rate repeated press actions. (instead of fixed-rate)
• B. Add a "shuttle-sign" variable, to make it easier for button-press actions to select the direction. (see my notes on issue Shuttle ring should trigger as repeated button presses (Contour Shuttle) #3491)
• C. (optional) only allow repeated press actions if a rotate action was not specified.

Alternatives:

• accept PR as is, recognizing that devices controlled by Companion are more likely to be able to handle variable step-sizes (and may have trouble keeping up with too many network requests...)
• add a config option to enable/disable repeated actions on shuttle rotate-left/rotate-right actions. (A downside of this is that 94% of the use-cases in my survey don't care about rotational direction).
• add an internal:repeat action (as in issue Request: Repeat button press when held #184)? (Again with downside about rotational direction.)
• do nothing (the current challenge is not insurmountable, merely clumsy/difficult to maintain)
• other ideas?...

[arikorn]

@Julusian I am hoping we can resolve this PR before it becomes too stale… I believe that you are on the fence about this PR rather than completely opposed, so perhaps we can find common ground?
To summarize my opinion:

1. Having the shuttle actions associated with a “button” (as it is now) is essential (a) for clarity, to keep it with the other buttons on the surface and (b) for functionality, to easily make the shuttle context-sensitive by putting the surface in a surface-group. For example, when the related surface -- such as a Stream Deck -- is on an audio page the shuttle/jog can adjust volume, whereas when it’s on a PiP page, it can adjust position. (This is something I actually do.)
2. The shuttle should allow repeated-press actions. If you consider the design of a spring-loaded shuttle-ring, it is a hybrid of a button and a knob: returning to “off” when released, but rotating as well. The conventional way to handle this is by allowing both repeated button-press actions and rotary actions, as can be seen in the manufacturer's own drivers, below. (If I had to choose, I would keep repeated-actions since as shown in the statistics above, it represents the majority of the use-cases.)

I would greatly appreciate your response on how we might move forward with this PR! For now, I will push an update that implements what I proposed in the previous comment, i.e. variable-rate repeated actions. (Note that while the update works, it will need additional work to merge with the current state of main.)