New zynthian user here, I just made a quick build with just a pi and a 7" touchescreen. I’m impressed ! I’d love to have the full hardware but for now I’d like to see if using just the touch screen it works.
One feature that would hugely increase ease of use would be to have +1 and -1 buttons on the select button. It works fine to touch and slide when you need to change for example a filter resonnance, but when selecting a bank or an instrument it moves too fast.
As far as I understand it, there is no other way to quickly browse all instrument patches without actually selecting one (for previewing purposes).
I have the feeling it is much more satisfying using a rotary encoder, but for those with only a touch screen, having the ability to press +1 -1 would mimic the real hardware.
I hope you see what I mean, and congrats for this wonderfull project!
I renew a request of @philippejadin
for a better usability with RPi+touch screen only Zynthian, so for only touch interface, I think it would be fantastic to have in the main mixer window a column of 4 configurable buttons (as the 4 buttons of V4)
This should not be required. Zynthian UI is designed to fully support touch-only when “Touch Widgets” is selected from the “Touch Navigation” option in webconf INTERFACE->UI Options. The documentation (although incomplete) details this mode if you select “Touch” from the UI selector in the top right of the wiki page. All navigation and workflows are implemented. Please detail what issues you are having with touch-only UI. (I spent a lot of time trying to make this work fully so am interested to hear where my work has fallen short.)
I’d advocate for the improvement of the already very handy v5 touch buttons. Probably it would be possible to make them configurable, maybe with the option of hiding those you might not need?
That might be a difficult thing maybe because these buttons need to be configured in the wiring section of webconf which might prevent a too dynamic approach, but not sure.
You mean a “v4” version of the v5 touch keypad showing only the buttons F1-F4? That shouldn’t be a big problem. We have discussed broader configurability elsewhere… well, I had, at least… never mind. There are various limits, mostly practical. Layout is limited by the display. Buttons can be configured relatively freely but their visual response currently not. And then questions such as who wants it and why.
I think @piattica means V4 touch buttons and I thought, it would be good to somehow meet these requirements but sticking to one already implemented method.
I’m afraid I meant exactly this. I thought about webconfiguring which function is presented as a touch button, on which side, in which size.
But I understand that these touch buttons have to correspond with the physical buttons visually and technically (wiring options).
There are 3 main input setups, V4, V5 and Touch with each some hybrids (like touch-buttons). Maybe one could resolve this by having the option to choose for every action if you want to have the touch, v4, v5, v5touchbutton or whatever input behaviour. So as an example you have the “Show Admin menu” option and you choose between “Touch bold title screen” or “Add 1 virtual touch button on right side panel” or “Bold press at Mcp23017 0x25 pin 114” or “bold press admin button”.
That is probably somewhere in the region of 10 squibillion permutations. Good luck trying to support that!
We have three supported input modes (V4, V5, Touch) and one sanctioned unsupported input mode (V5 onscreen buttons). We have full configuration for binding hardware switches and encoders, keybinding and MIDI binding and also OSC control - which may be used to create custom hardware interfaces.
This is already a lot to support (officially and through community effort). Who fancies asking Korg if they would add the ability to control their Kronos with some different on-screen buttons?
Sorry - that all sounds a bit grumpy… I just want everyone to understand that zynthian is already one of the most configurable audio and music making devices available and such configuration and flexibility has a support cost. Lets not extend that cost without good reason. But also, lets not stifle debate and new ideas for improvement.
My wife tells me that there is a “one in - two out” policy on music keyboards in our house - maybe we need a similar policy on UI paradigms.
Edit: Please note that I’m not requesting anything but just debate the request above.
Completely understandable. My comment was just about the request above to add 4 touch buttons and I was arguing to stick to already present methods. I’m actually totally fine with the current behaviour.
The method based on the thoughts above though wouldn’t add anything. It would just flip the configuration from “select an action for a given input device” to “select an input method for a given action”. The selectable input methods would be the same (official or custom buttons, touch buttons or touch control). Don’t know if this could resolve having 3½ input methods to just one configuration scheme where the end user could achieve all 3½ existing ones or even something else.
This would, BTW, meet the “1 in, 3½ out” requirements.
I tend to get a broad smile when I read the word “just” in a suggestion… it is rarely a simple solution. We have events and actions. Several events can be mapped to trigger an action. This is a many-to-one mapping scheme. The subsytem monitors events and looks up what to do with them. Flipping this means changing to a one-to-one (more limited) or one-to-many mapping (complete opposite to current logic requiring all event subsystems to be refactored).
Maybe the suggestion is to view a list of possible actions and see what events trigger them?
I don’t see the benefit but am eager to better understand. Just because I don’t understand does not mean an idea has no merit. (I would need to be a megalomaniac to believe that! Are megalomaniacs self-aware???)
Exactly this. Without any change of the underlying system. It would abandon the need of choosing touch/v4/v5/virtual buttons from what I understand. Just one control scheme where the end user chooses if admin menu is shown by bold pressing title bar (current touch behavior)/physical button(v5)/virtual button(v5 touch)/S1 Button(v4), maybe even and/or.
I mean, the current behaviour does this already, right? Moving from “touch” to “touch buttons” means moving “menu” from “touch title” to “touch menu button”. Moving from v4 to v5 means moving from “bold press layer encoder” to “short press physical menu button”. If you’d give the choice in the hand of the end user you can stop maintaining 3½ input schemes.
So you could mix them in a custom build as well.
UI wise it would mean that the appearance of the virtual buttons would need to acquire screen space dynamically.
But my assumptions of the techniques might be limited.
The underlying system stays the same. The wiring options stay the same, you’ll assign if there are 4, 20 or any other numbers of buttons. You’ll still state -1 for any virtual (touch/virtual buttons) or positive numbers for gpio buttons (v4/v5/custom).
The webconf wiring system would present a list of all possible actions, where the user assigns to each action a trigger event with seperate options: button #No; trigger duration [short/bold/long]; trigger type [touch/virtual button/physical button]
If trigger type “touch” is choosen, you get the choice which screen area to touch (title/status bar…)
If trigger type “virtual button” is choosen, you get the choice to which left/ríght/top/bottom panel a virtual button is appended dynamically.
The configured virtual buttons (if so) are appended in one line, if the number of buttons on a given panel exceeds the space, a second row is created. Cursor buttons will be automatically appended left or right bottom side like the current behaviour. The known controls are the basis of how the screen estate is used afterwards. The size of the virtual buttons can be user defined.
Up to three actions can be assigned to the same button #numbers for [short/bold/long]
That way you can abandon wiring layouts like V4/V5/virtual buttons/touch only completely. There could be preset layouts for most typically work cases (official V5.1 and so on) anyway. I think any official/common layout can be implemented like that as well as any custom setup. Let’s say you have a custom build with 8 additional buttons. You would assign them to physical controls, the other 12 you assign to 6 virtual buttons on the left and 6 on the right.
But again: I don’t want to stress the topic so much. I actually like the current layout and I just discuss about thoughts I have about the above mentioned request by @piattica and how it could be avoided to have different requests for additional touch buttons for different purposes by just making it configurable within the current system.
This is where the squibillion permutations comes in. For there to be a full list of possible actions you need to have every permutation of every CUIA with every permutation of parameter values. That is literally millions. I would not want to traverse the list in webconf, when it eventually finished rendering the page!
Like I said, I don’t want to stress this. But I don’t understand how it can be millions of permutations. I mean, in the current state you assign ~30 possible actions (don’t recall exactly) to 20 possible customizable buttons and add the informations like duration and values accordingly. The other way round you’ll assign 20 customizable buttons to ~30 possible actions and add these values.
Current behavior: Select a customizable switch → chose if triggered with ALT → chose duration → chose action → chose value if applicable (managable million permutations)
Proposed behavior: Chose action → Select a customizable switch → chose if triggered with ALT → chose duration → chose value if applicable (managable million permutations)
But maybe I do not see something. If the idea is totally nonsense just tell me and I’ll just stop.
Anyway: the proposed user customization could be done without these changes I guess. One could just add a dropdown menu under each customizable switch which asks if the switch should be a touch screen area or a virtual button appended to left/right/top/bottom.
If you want a button to set the tempo to 120 BPM you can do that by targetting “Tempo” with parameter 120.0.
If you want a different button to set the tempo to 83.2 BPM you can do that by targetting “Tempo” with parameter 83.2.
With a reverse mapping, we need options to set tempo to 10, 10.1, 10.2, 10.3… (that is a lot of options). Or we could have an arbriatary quantity of “Set Tempo”, each with a parameter then some clever logic. Or we could have a dynamic list that we can add as many “Set Tempo” options, checking that each is unique.
I don’t think that mapping triggers to events works.
I see the point now. You would not add thousands of options but a “value” field, but the question would be how to dynamically multiply the entries.
I don’t see the urge of a button for a static Tempo change but some users may require it. I would rather have a Inc/Dec Tempo by 1.0 or so, or chose next/previous preset action.
Anyway:
That was more my point I guess. I’d really love the option to bind triggers to user defined controls.
when you are playing so that is why I an suggesting a shorter way
