I know why I actually want it, because when /CUIA/V5_ZYNPOT_SWITCH is used, it should be recorded in the workflow capture. When I use /CUIA/ZYNSWITCH, they are recorded in the log, but when playing the video it doesn’t show that the knobs were pressed (for V5 layout).
1 Like
Hi @ToFF! I am in the countdown to my holiday when I will be off-grid so not in the right frame of mind to engage with this here now. Will you please add a feature request to the github issue tracker? It won’t get done before oram release later this month so I don’t need to worry about it for a while. 
3 Likes
Sure, I’ll probably add it to the queue with other OSC / CUIA ideas. Enjoy your holiday,
3 Likes
OK! It’s increased now. Update and test, please.
Regards,
1 Like
Thanks. No more worries about updates breaking the working setup! 
I can also confirm shutdown by power button is clear now. (I noticed you have done a lot of work there!)
2 Likes
Yep! It was harder than expected.
Just to test that the configuration for the “v5touch” extension can easily be added into the webconf (incl. a wiring profile for zyncoder), I created forks for both of them and tried…
Adding two more Pull Requests:
2 Likes
More news on “v5touch”: button colours and labels are now configurable from the UI as well (using my fork of zynthian-webconf, at the moment). This would probably be most useful for the F-buttons, because…
Well, you can configure your own labels in the UI settings for all the buttons, and you can also change their actions in the wiring settings, but there is (AFAIK) no way to change the fixed visual response of the buttons (like for the original wsleds / RGB LEDs in the V5 physical buttons). For example: you could assign another “Program Change” action to the first button (i.e. “OPT/ADMIN”) and you can also change its label on the touchscreen, but its colour (nor label) still won’t respond to pressing “Alt”. The button is just not expected to have an “Alt” state. On the other hand, its state (colour) will continue to reflect the fact, whether the OPTIONS or the ADMIN menus are currently displayed or not (e.g. using the standard touch navigation). So, the “input” properties are fully configurable, but the visual response (feedback or “output”) - i.e. the actual triggers changing the state of the button - cannot be reconfigured.
2 Likes
The logic behind LED color feedback is not easy to configure. It depends of state and normally requires some code. Indeed, it can be redefined for each “view”, same than transport buttons and “ALT” mode behavior, what still complicate things still more.
You can define default ALT actions for each “zynswitch” (button) from the webconf, but currently this is not used for LED feedback, that is “hardcoded”. It could be interesting to improve this, so the LED feedback code take care of the default ALT action assignments instead of using a hardcoded list. It should be studied but it sounds doable. Please, open a “feature request” so this is not forgotten.
Regards,
1 Like
I am afraid this is a more complex subject. Rather a long time goal in the architecture of Zynthian than just a simple “feature request” (but we can still try to formulate one).
There is already some partial abstraction of the controllers (“switches”). This would also require some abstraction of the “states”, for any response/feedback indicators. (Currently, different parts of code just spontaneously change the colour of particular wsLEDs, not even associated with the buttons.) This would thus demand a system of “states” and methods to report their change. I guess I already mentioned somewhere that OSC messages reporting state changes on a subscriber-subscription principle would be a great feature. You could bind various actions and indicators to them, like you can bind CUIA/OSC actions to the input switches now. (However, most sound engines (where this would be most beneficial) probably don’t always offer such features, I suppose.)
So, we can try to formulate a specific “feature request” to start with, but there is a lot to think about and you are probably more down-to-earth than me to make it more concrete.
OK, I opened feature request #1223. The initial formulation is very vague as is my current idea about the possible implementation.
1 Like
V5touch updates:
- the V5 touch keypad can now be turned on/off* from the UI (Admin menu)
- labels for the F-keys can also be customized (edited) from the UI Admin menu; they are saved/restored in the snapshot and override defaults from the environment settings
*) Note: the switches 1-20 must still be configured in the wiring configuration in webconf to actually trigger any actions! This only changes the visual layout of the UI.
1 Like
it’s fully OSHW.
ANd also, on Ali, these unknown mechanical switches that are really affordable (extremly low cost is the word)
V5touch updates:
Created new Pull Requests for Vangelis. (In case someone already uses my fork: up-to-date Oram version is now within a branch also called just “oram”, not the “v5touch” branch of the zynthian-ui.)
4 Likes
Just update of instructions for those who want to use the V5 touchscreen keypad. Things are much easier now in case you are on the “vangelis” (recommended) or “oram” branch:
- Until merged into upstream: Go (in terminal) to
/zynthian/zynthian-ui/and edit the file.git/config. You need to change the URL from the originalhttps://github.com/zynthian/zynthian-ui.gitto my forkhttps://github.com/wanthalf/zynthian-ui.git. Do the same within/zynthian/zynthian-webconf/. Now, you can just update your Zynthian. - In the hardware settings, select the “Wiring profile” named “Mcp23017 Encoders V5Touch” (it should be OK even if you don’t use any encoders). You may adjust it to your HW, of course, but there must be configured at least 24 switch PINs.
- Now, you can turn on the touchscreen keypad either in the “Interface” > “UI options” or in the “Admin” menu of your Zynthian.
Within the branches “vangelis” and “oram”, I am merging the changes from upstream almost daily, if I remember (it’s mostly just a two click action).
You can edit your custom F-key labels (F1-F8) from the “Admin” menu in Zynthian. They should be stored (and restored) within your snapshots. In the WebConf settings, you can change default labels and colours for all the onscreen “buttons”. Changing left side and right side button layout is also possible both from the webconf “UI options” and from the “Admin” menu.
4 Likes
What is the utility of this? Why would you want to customize these keys labels from UI admin and store with snapshots?
These keys are normally used for zs3 and we already have a mechanism for naming zs3s. Why not using zs3 names for the labels?
Please, explain the use-case so we can understand the reasons to include this.
BTW, splitting the development in smaller pieces would help. In its current state it’s a little bit overloaded of config options and this is slowing the merge.
Moving the webconf config options to a separated panel would help too. Too many UI config options IMHO.
All the best
1 Like
Hi. Thanks for taking the time to have a look at this and providing feedback. This is what I was waiting for. And sorry for my lack of insight.
Excellent! Than we can show them as labels! (Unless they are very long…)
I supposed that the F-keys can also be used for other custom functions and purposes. But if the switching of zs3s is the only established use and anything else is marginal, we can remove the custom renaming as superfluous.
Yes, I thought about that too, but I wanted to wait for your judgement before doing any structural changes of such an extent. Maybe the options are just too extensive?
My humble motivation:
- I am just obsessesed with customizability and generalization, sorry for that personal vice!
- I want to demonstrate all the possibilities. They can be always removed if undesired or overabundant.
- I was exploring the possibilities of both the Zynthian environment and my implementation. I learned a lot!
The practical motivation:
- colors: we discussed this a lot and found there is a big difference between our individual sight, preferences, but also our displays. There are already abundant possibilities to configure the UI colours so I just got encouraged and followed the same pattern
- labels: since the user can assign virtually any custom function to any button/switch short/bold/long press, I thought he/she should also be (in principle) allowed to assign custom labels to the buttons. There are many actual limitations for the V5 buttons though: some buttons have Alt function and some don’t, some have two states, the transport buttons have hardwired indication of state… so that it is not really possible to customize anything but the F-buttons. So, maybe this configuration is currently just superfluous…?
Anyway, the “hackers” can always use the environment variables to change things. We don’t need to overload the webconf UI. (I just felt the already overloaded “Advanced” mode may bear everything :))
Let me know your opinion and I will remove what seems superfluous!
I agree. It is my first PR to other people’s code so that I was surprised myself that all the changes just accumulate continuously within the PR. While waiting for feedback, I tried to add more and more features… But I can remove them again or split if I find how. Is it possible to withdraw some commits from the PR, or fix the PR to particular commits only? Or do I need to split branches for every single feature?
Anyway, I will either find out how to do that or just remove the superfluous additions. Thanks a lot!
6 Likes
No more comments, opinions, suggestions… OK, I have completely removed the configuration of custom labels in the UI and their storage in snapshots from the PR #506 (zynthian-ui) and the configuration of colours and labels from the PR #188 (zynthian-webconf). At least for now, we can discuss further steps later.
Please, let me know what else I can fix or improve to make the PRs acceptable, @jofemodo. Thanks.
2 Likes
Hi @wanthalf !
Let’s go forward and merge this ASAP. I will check your latest changes tomorrow and will try to merge. Please, review my latest changes in Vangelis because i fear there will be some conflicts (but you will like what is coming!) that you would need to merge.
Let’s hope this is the last time you have to do it, mate!! You deserve spending your time in more productive tasks!
All the best!
2 Likes
No conflicts indicated, so I just merge. New screens to adapt? Need to look closer… there are some fancy improvements in the air, though.
1 Like