Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper "touch" automation #813

Open
1 of 5 tasks
p0nce opened this issue Nov 10, 2023 · 3 comments
Open
1 of 5 tasks

Proper "touch" automation #813

p0nce opened this issue Nov 10, 2023 · 3 comments
Labels
Bug Reproduced bug. Documentation This issue is about documentation.

Comments

@p0nce
Copy link
Collaborator

p0nce commented Nov 10, 2023

"Touch" automation works for knobs and sliders but not press buttons. It makes erratic moves instead of cleanly reverting to automation start point.

I think this is because in a mouse gesture, the beginParamEdit/endParamEdit must match the click and unclick, which is not the case for every widget.
Easy to see with Inner Pitch Full, automating press buttons there.
Can repro in a DAW with so-called touch automation, such as Luna, Logic, Protools...

  • Increase the documentation
    • of beginParamEdit / endParamEdit
    • of onStopDrag
    • of onMouseClick (warn about new clicks coming)
  • Solve that problem wherever it happens in examples

Interestingly, this is finally an explanation for why should beginParamEdit and endParamEdit need to exist.

@p0nce p0nce added Bug Reproduced bug. Documentation This issue is about documentation. labels Nov 10, 2023
@p0nce
Copy link
Collaborator Author

p0nce commented Nov 22, 2023

  • Big question: is the gesture that start with a double click or ALT + click (reset) is the same gesture in touch automation with the following widget drag? Need to take a decision on this based upon best practice. ANSWER: yes, but most host can deal with double-click and ALT terminating the param edit before start a new param edit. Where is doesn't work is with FlatSwitch and such widgets.

List of incorrect widgets:

  • Flat Knob in case of double click, should not initiate a drag operation. If it does, stay in same "param edit" scope. => EDIT no need to deal with that
  • Same for PBR Knob => EDIT no need to deal with that
  • Same for PBR Slider => EDIT no need to deal with that
  • Same for Flat Slider => EDIT no need to deal with that
  • Fix UIImageSwitch
  • Fix UIOnOffSwitch
  • Anything that isn't working in Studio One / REAPER / Bitwig in touch automation, but that is more in the Auburn plug-ins.

Yeah. Almost all widgets are wrong but this doesn't break user sessions thankfully, it's just quite dangerous as a change.

@p0nce
Copy link
Collaborator Author

p0nce commented Nov 23, 2023

Studio One has "touch" automation, could be useful to repro.

  • no issue with PBR Slider or Knob, double clicks and alt clicks correctly return to original
  • no issue with Flat sliders or knobs
  • but issue with "Soft vs Hard" switch in Clip It indeed. Return to original while the mouse is still down.

So Studio One is more permissive than Luna with regards to this. Is this common across DAWs? We can expect Luna to handle this maybe.

(EDIT: exact same behaviour in REAPER than Studio One)
(EDIT2: mostly same behaviour in Bitwig too, just Switch has different failure mode there)

=> Most host can fusion adjacent periods of beginParamEdit/endParamEdit to deal with what plugins do. Luna just doesn't do it yet. We only need to fix switch-like, radio buttons, push buttons, likely.

@p0nce
Copy link
Collaborator Author

p0nce commented Nov 23, 2023

Super-tricky a widget that call beginParamEdit in onMouseClick must deal with right-click coming while a drag is already there. This might produce

  • "fixed" switches fall prey to this; must have state enum.
  • Knob not affected by this, since beginParamEdit/endParamEdit is called as part of dragging, but a double right-click or ALR + right click would break that. This creates additional beginParamEdit/endParamEdit unfortunately.

p0nce pushed a commit that referenced this issue Nov 23, 2023
…h automation: the value will return to original AFTER the mouse is released.

The general rule seems to be that endParamEdit should be called in onStopDrag.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Reproduced bug. Documentation This issue is about documentation.
Projects
None yet
Development

No branches or pull requests

1 participant