You didn’t respond to this point that you quoted.
At the beginning, I was hoping to implement it using the current methods for on-demand buttons (you may remember, it must be mentioned somewhere above), but did not find it really suitable for this purpose - but maybe I just didn’t understand the system correctly, which would be just my fault.
Even as static buttons (which is what I actually wanted), I also thought about an easier possibility to turn them on and off without restarting the whole UI, but that would require much deeper changes to the whole UI structure.
In the end, I actually don’t really see a reason to make these buttons dynamic instead of static. As explained above, the point is to use the additional (superfluous) area on a larger touchscreen and substitute the physical buttons. Either you want to use them for quick access to various screens and functions, and then you want to have them accessible all the time, or you can just do without them and then you don’t need them at all. They are not really necessary and so they don’t really need to appear and disappear depending on the context (screen).
HOWEVER… of course some of the buttons are more or less useful in different contexts. And for different people. For example the function buttons may be unnecessary when configuring something or setting up things (but for the menus you usually don’t really need to free any extra space anyway), but useful all the other time. The arrow buttons may be completely unneccesary all the time, if you just use touch navigation and scroll using the encoders. And so on. That is also a reason I though about alternative configurations with some of the buttons (e.g. the arrows) replaced by additional function buttons, which may come handy to many people for quick access or triggering something.
So, yes, fully customizable and context dependent dynamic buttons on demand would be a useful concept too, but it would probably need a very complex extension to make everyone happy and configure what he wants to (dis)appear on which screen and when. I don’t know. You are the designers.
So, this implementation is just a simple solution to a simple task: replace physical (static) buttons with the superfluous area on my screen, which is so large that I don’t really need to see the standard zynthian widgets magnified to its full screen anyway (also because it actually looks ugly to me).
Of course, if the large area of the larger display could be used for more widgets, more columns in the mixer, better overview over complex menu trees aso. - that would change something. But I still might want to have some static buttons available and visible all the time, instead of some physical ones, maybe?
I thought that’s the VNC issue, isn’t it? I responded to that one. Maybe I should have split it in a better way, sorry…
Kind of VNC - if you hover over a button it changes colour and you can leave a button highligted which looks odd. I would prefer there be no button highlighting.
I appreciate the purpose of this work was to utilise the extra screen space and so I mostly ignored it until now because I didn’t see much overlap but having been asked to test and used it for a while, I can see how the concept of buttons appearing and disappearing could have merit… or to take a different view, to see the screen shrinking as needed to show extra buttons. Hence my observations about that.
The mixer already changes the quantity of fader strips based on screen resolution. If you increase your horizontal resolution you should get more faders.
1 Like
Oh, I see, so you use a mouse connected to the Zynthian? I actually haven’t thought about that combination at all. 
OK, we should then somehow solve that postponed issue. As mentioned, I couldn’t find a solution until I gave up and kept it for later research, but there must be one that I just overlooked!
Oh, does it? Maybe the problem is that the physical resolution of the screen (1024x600) is just not adequate (in comparison to the screen size) enough to make relevant changes I would notice?
Anyway, that would call for a more DPI dependent scaling. Or maybe user-adjustable? Some people prefer larger widgets, some smaller… and it (unfortuntaly) changes with our age. Also, the displays are very different - in size, DPI, quality, the distance you are actually looking at your Zynthian, etc…
Tested it on a V5.1-style hardware and the touch buttons show with blue caption, once pressed, caption disappears, touch buttons stay functional.
Knobs have no function. I’d guess it definitely needs a V4 hardware to work, right? If so, this should be clearly comunicated on the Webconf options.
Disappears? You mean the button turns completely black?
The configuration is just a custom configuration of mine and needs to be adapted according to your hardware. When you set up wiring profile to “V5”, it just does everything automagically for you and does not show you all the details, but they are still preconfigured there in the code. My wiring of the MCP23017 is the same as in V5, I think, but the encoders are wired differently to the MCP than in the V5. So that you would have to fix the pin numbers of the encoders to their actual V5 configuration… and there you need to look at the schema in KiCAD, of course.
Disappear. No text. Completely black with light grey borders.
The hardware is V5.1, exactly, only without the i2c headphone amp, so it has the exact pins used for encoders and keys and RGB-LEDs. I can use profile V5 and layout V5 and everything works, but no touch-buttons.
Only the hardware kit selection does no work with the setting V5, because with this setting it does not find the i2c headphone amp and drops into a lock-up.
If I select MCP …V5 touch, it does not work, instead shows the broken buttons with disappearing text.
So I don’t understand what you want to say.
Ideally, it should work without any i2c hardware at all, or with whatever i2c connected, because touch is there to replace the i2c hardware buttons (!) or did I get something wrong?
Oops. Obviously we have some misunderstandings here on both sides…
Of course, you don’t need any hardware. I thought you refer to the “rotary encoders” not working, when you said “knobs”.
Actually, you should be able to just keep your current wiring profile settings for V5 and just turn on the touch keypad. It will surely make things just small and ugly on the 5" display, but the buttons should show the very same colours as the V5 buttons… wait! No! If you switch on the touch keypad, the driver for the wsleds in the buttons gets replaced with the “fake” wsled driver for the real LEDs in your buttons!? So those should probably stop lightning/changing colours. Am I wrong?
Maybe, @riban or @jofemodo can tell use more. I have neither the hardware nor the proper insight into all the consequences of the “V5” wiring profile.
I am involved in this dicussion because of the desire to merge the touchkeypad_v5 development into zynthian mainline development (vangelis). On that matter we need to consider:
- What benefit does it offer?
- How well does it integrate?
- What support overhead does it present?
I would like to avoid integrating something that consequently becomes challenging to maintain, especially if the target userbase is very small. To that end, I would like to ensure that we are clear on the benefits and scope of this UI enhancement.
If the purpose is purely to emulate the hardware buttons and LEDs then we should be absolutely clear on this and avoid the temptation to integrate more features into standard zynthian workflows (as some of my previous observations relate to). I would suggest that this would also support the removal of the option to switch UI from admin menu. You either have LED buttons or you don’t.
Acting as an emulator for the LED buttons should integrate directly into those elements. There should be a one-way host, i.e. either touchkeypad hosts zynthian_gui or zynthian_gui hosts touchkeypad. It should be extensible and use core zynthian configuration, i.e. when we enhance or change behaviour of V5 buttons, touchkeypad should pick these up without further development.
We have spent a lot of time and effort designing the zynthian UI to work in three modes:
- V5 - 20 LED buttons, 5" capacitive multitouch touchscreen, 4 rotary encoders with push switches.
- V4 - 3.5" resistive touchscreen, 4 rotary encoders with push switches, optional 4 push buttons.
- Touch only - 3.5" or larger, single or multitouch touchscreen.
The workflows are all tested including navigation and documentation is written (wip) for each of these workflows. It is very challenging to design and document for multiple workflows and we don’t want to expand this, so I would recommend that touchkeypad_v5 be constrained to what it was originally envisaged: to emulate the V5 LED buttons on a 7" or larger single or multitouch touchscreen.
Please @jofemodo & @wanthalf confirm this as our position. If so, we should revisit the question of merging into vangelis within the scope of this decision. (Sorry for taking us off on a tangent but I only had a 5" screen on my test rig an so did my testing with that, which incluenced my feedback.)
1 Like
Just to clarify:
-
v5touch is currently merged in vangelis. No discussion about this.
-
V5 touch keypad can be enabled in any V5 / V5.1 / MINI and it works as expected without modifying anything else. Logically, Physical buttons LEDs get disabled. Obviously, if you have a V5, you don’t need/want the touch keypad, but it’s nice to test and see how it works. BTW, the admin’s menu option is disabled in V5.
-
For any other hardware different to V5 / MINI , you should select a proper wiring layout to get it working. @wanthalf has included an example called “MCP23017_ENCODERS_V5TOUCH”, that is thought for a hardware layout including 4 encoders with switches connected to a MCP23017 and no other buttons. For using touch keypad with other hardware configs, this must be adapted.
Indeed, @stojos , we should avoid this step and get things working out-the-box for pure touch devices. Let’s think about it, mate 
Regards,
2 Likes
as long as touch and some or all other than MCP23017_ENCODERS_V5TOUCH are mutually exclusive, this will lead to confusion.
It should better be parallel, reading from current wiring configuration (= reusing these settings to define the buttons and knobs) and emulating these hardware settings, whatever hardware is actually present. This would give the opportunity to test, develop and customise emulated things without actually soldering off pins and wires.
Or do I get the idea of touch-style hardware emulation wrong here? Then I must apologise… 
There is an observable latency in the button labels chaning colour after a state change. It seems observably longer than the V5 updates its LEDs.
1 Like
I just added some magic so zynthian devices configured as “dummies” will work out-the-box without configuring anything extra. This should cover all pure-touch zynthians.
Regards,
@jofemodo this sounds like it might be helpful for the Mackie Controller device, what change did you make ? Thanks
No. It’s unrelated. Ctrldev drivers are no related to this.
Regards
I extended the dummies wiring, 15 * ‘-1’ to allow for more Zynthian buttons with Press and Release, perhaps it could be related
I found the “magic” 
“Add 4 extra custom switches (logical) to dummies config.”, it does affect what I’m doing, I’ve been following this channel very closely as the discussion has been very helpful for me, quite different use cases but similar issues with buttons. I was thinking of a bit of magic of my own which would involve no user integration but only if the driver is loaded and the user has a dummies config.
Hi @chrismat !
You should avoid calling switch actions in your MIDI ctrldev driver. It’s not a good idea. You should call specific CUIAs instead .
A Ctrldev driver should not depend of the wiring layout.
Regards
1 Like
Well that put me in my place!
I’ll continue to develop it for my personal use then, if others like what I’m doing they can use it otherwise adapt it to how they want it. Feel free it’s open source and available on my fork. I’ll let you know when I consider it to be stable.