Simplified click behaviour #155
Conversation
Click = Select or Confirm DblClick = One Level Up TripleClick = Home
|
Hello @fp64lib, welcome to the project. I will test this for a while and see if it makes one's life indeed easier. |
|
Yeah, keep backing out of menus by mistake, much better implementation. |
|
For those who want to test: |
|
The logic problem arises when you can select something (go "down" in the menu) and can go out of something ("up" in the menu). Then you have to double-click. Isn't that hard to explain and understand? |
No, the default is to select, i.e. to go down. Single Click will always go down, DblClick will always go up. So fo the "middle" layers, where you can go up and down, Click will always go down. This is basically just swapping the behaviour of Click vs. DblClick. Only, when you can no longer go down, Single Click will confirm and automatically go up, thus avoiding the additional DoubleClick needed to escape the lowest level. |
It's now configurable, whether a MIDIProgramChange message changes the voice or not, controlled by the parameter MIDIRXProgramChange in the minidexed.ini file
|
I am hesitant. While I see how this could speed things up, it also makes things illogical to explain and may be confusing. Once we can map MIDI controller knobs and buttons, there won't be as much need for menu-diving anymore... |
|
For what its worth,my vote is for the simplified click behavior. Ive been using this version the past week and definitely prefer a single click vs double click to advance. For me( and i suspect many others,) a single click is way more logical and intuitive. I hope that this gets merged.... or at least a option to choose. |
Parameter EncoderClickIsConfirm switches between two UI behaviours: =0 (or missing): Default behaviour: click is Up, DblClick is down <>0: Fast mode: click is confirm, DblClick is up
|
|
Nice! |
|
Available for testing: |
|
No ill side effects in my testing. So the only downside is that the code gets a bit more complex, and that it becomes more complex to explain and document how things work. How would we describe this feature in the documentation so that it is short and understandable? |
|
maybe something like this: "Default menu navigation is 2 click to enter/go down , 1 click to return/go up. Alternately, one can change the navigation behavior to 1 click to enter/go down and 2 clicks to return/go up by adding the line "EncoderClickIsConfirm=1" in minidexed.ini In either case, 3 clicks returns to upper most menu level. " Seems obvious enough, at least to me. |
|
I would describe it as follows: If you do find it difficult to navigate using the default "double-click for down/click for up" behaviour, try setting "EncoderClickIsConfirm=1" in the config file minidexed.ini. This will swap the behaviour of click and double-click: click will now navigate you "down" in the menu tree, double click will navigate you "up". Furthermore, the option EncoderClickIsConfirm=1 will also help you setting several parameters with less clicks. When you are at a parameter, there is no more submenu and both double-click and click will bring you back to the previous menu. So, it's easier to memorize that single click confirms your selection, i.e. you either open up a submenu or you confirm the current/modified value of the parameter. Small example for changing the voice, volume and pan of TG1:
|
|
I really like this behavior. I find double-clicking to be completely non-intuitive for entering menus, but very suitable for backing out of them (and I recall similar behavior from watches and clocks). Could we have this merged, or turned into an option? |
|
@fp64lib when you get a chance, please update this branch and hopefully it can get merged! I too am eager for single click |
|
Can we have two options in the
Reference: |
|
Somewhere else I saw click to enter menus and long-press to exit menus. |
|
@fp64lib thanks for this PR. In the meantime, additional requests for configurability have led to #274 which should allow users to configure the buttons quite flexibly. Please give it a test; I think we might close this PR in favor if #274 which gives users even greater flexibility in configuring buttons. With the following configuration you get single-click to enter/select and long-press to cancel/back: But it is also possible to use, e.g., an extra button for cancel/back. |
|
@probonopd Thanks for the update. I'm currently on holidays without any chance testing it. I will do so after returning home in about 2 weeks. |
|
Would like to close this in favor of #274 if no one objects. Please do test the build from that PR and see how well it works for your use case. |
|
Closing in favor of the more flexible solution that has now been committed. Thanks to everyone who contributed to this! |
The current implementation for the menu navigation is following a "GUI" approach with a mouse with Double Click for selecting an item & Single Click for upwards navigation. With just a rotary encoder, especially changing Operator behaviour needs a lot of clicking. I tried to optimize the behaviour towards less clicks with the following rules:
Single click: "Confirm", i.e.
Double click: "Up", i.e. goto into the previous menu
Triple click: "Home", i.e. goto the root menu (no change here)
Here a typical use case on how this reduces the number of necessary clicks: Select a new voice and adjust "Volume" & "Pan" for it, e.g. for TG1
As user interface behaviour is sometimes very tied to the user and the inventor, I will not fight for this pull. This change works for me very good, I have the feeling that I am much faster at tweeking paramenters. But before rejecting it, give a try, start a jam session for 1 hour, where you experiment with the voices and the parameter settings, tweaking operators etc.
Otherwise: awesome project, keep developing it. With that, I do not have a dedicated hardware "DX7" in my setup!