the buttons have actions defined for PUSH, SHORT RELEASE, BOLD RELEASE and LONG RELEASE - but the “BACK/NO” button has the BACK action applied both at PUSH and SHORT RELEASE…?
states: the ALT state is obvious, but how / where are the other states implemented?
– the screen access buttons need to know whether they are already in the state of first action active, so that they should apply the BOLD action on the next SHORT press…? I see how it is treated in the wsled RGB color module, but how about the actions triggered?
– the transport buttons have some different action when in pattern editor screen or audio-player chain: how do they know and what CUIA is triggered in those cases? just the same one, but reinterpreted somewhere else in the system?
some buttons do also have some MIDI or CV values other than 0 associated…?
We do display some of these, e.g. in the status bar. I think we use unicode characters.
Please raise a ticket.
Please raise a ticket.
The V5 Wiring Layout with V5 Customization Profile configures Switch-13 (V5 BACK/NO button) as “Ui Action Push” with the “Push” action as “Back”. This means that only the press action will trigger the CUIA “Back” which will trigger a view’s back action if it has one. No switch modifers occur with this button, e.g. bold press is ignored.
There are some actions mapped globally to some button events. These are mostly long press, e.g. long menu shows the admin menu. Each view (screen) has handlers for encoder, switch, CUIA, etc. (Mostly CUIA is done in zyngui but some screens have handlers that zyngui calls.) These handlers may be in the base class or a derived class. There are also some special (historical) handlers, e.g. switch_select, back_action, etc.
Each switch may be bound to various action types. The push button types are:
Ui Action Push - triggers only on the initial press. Only the on_press action is processed
Ui Action Release - triggers on release, hence supports short, bold & long actions. The on_press and on_release actions are processed.
CUIA accepts a list of parameters. Some actions require no parameters. Some require one parameter which is derived from the value specified in webconf. Some require more parameters which are derived from a comma seperated list defined in webconf. There are some CUIA that accept parameters but have default behaviour (default parameter) so do not require but can benefit from a parameter. This wiki page describes the CUIA actions and their parameters. It may be out of date but is probably the only documentation we currently have.
Thanks for very useful hints! I have found the state dependent switching in the CUIA functions (except of the screen switching yet, but that’s not that important just now).
It brings me back to the question whether I could just use the abstract “ZYNSWITCH” CUIAs to avoid dealing with the CUIA action mapping. But I might then need to activate some V5 profile to activate the actual swtch->action mapping? I would then only need to implement the timer for short/bold/long press and nothing else?
The CUIA parameters seem to be part of the string. E.g. “V5_ZYNPOT_SWITCH 0,L”. So that the _CV_CHAN, _MIDI_CHAN, _MIDI_NUM and _MIDI_VAL suffixes must play a different role.
So, the switches marked as UI_ACTION_PUSH only apply the PUSH action and all the SHORT/BOLD/LONG RELEASE actions are just ignored? I ask because e.g. the button no. 14 (arrow up) is such a case, but it still has SHORT and BOLD RELEASE actions configured to trigger the corresponding “ZYNSWITCH 3” actions. Just a historical relict/mess?
Yes! The timed actions (except long) occur when the switch is released. Because we want the button to trigger an action on press, we don’t want subsequent actions being triggered on release or when the long press occurs.
This looks like stale configuration in zynthian_envars_V5.sh. @jofemodo may want to clean that up. As you see in webconf, when action Ui Action Push is chosen, you ony have the Push and ALT Push triggers available.
Yes, this is an option for HID keyboard binding. If you want an onscreen button to act exactly like a physical switch then use ZYNSWITCH switch# where switch# is the index of the switch, starting at 0 for legacy encoder switches and 4 for additional switches.
This requires the quantity of required switches to be enbaled in hardware. These additional switches can be configured with -1 as dummy switches. Then you may select a profile or manually bind them.
No! The timing is already implemented. If you map to ZYNSWITCH then the button acts exactly like a physical switch with its press, release, short, bold, long actions. (BTW If you bind to ZYNPOT then the buttons also autorepeat.)
No! The timing is already implemented. If you map to ZYNSWITCH then the button acts exactly like a physical switch with its press, release, short, bold, long actions.
According to the documentation, the second parameter of CUIA ZYNSWITCH should already provide the resulting action type Push/Short/Bold/Long. If the subsystem should to do the timing, it would only need to get signals for initial push and final release.
The HID keybinding allows a key to be bound to a switch. The switch action is then simulated (push/release). This then gets interpretted based on the switch config, e.g. setting timing. So if you do the same as the HID binding then it is already handled. We don’t want to add even more timing handling - indeed this is why HID keyboard binding was done that way. You can bind to specific triggers (like bold press) or you can bind to the switch and let the switch handler do the interpretation.
In zynthian_main.py at line 165 the keyboard key press and release events are bound to cb_keybinding callback which in turn adds the appropriate press / release event to the cuia_queue. That is subsequently handled to provide appropriate CUIA call.
So, there are actually more ZYNSWITCH action types, including the one for "R"elease. And triggering "P"ush and "R"elease consequently does really treat all the timing and trigger the corresponding Short/Bold/Long actions. (So, the other implementation of timing in zynthian_gui_base.py is probably completely unnecessary.) So, it looks like it really works!
Now back to the visual side. The Audiowide font does not seem to include any useful unicode symbols according to my computer’s font inspector. Surprisingly, it actually displays at least the unicode “STOP” symbol on the zynthian screen. But nothing else.
I had thought there was vertical space for two rows of buttons but there is not so you can ignore this suggestion.
Will you please point us at that code so that we can assess its purpose. We like to remove obsolete code but if it is not, then we can explain why it is there.
Most of the fonts available on Zynthian have a limited set of Unicode characters. Always test against the installed fonts. It is the higher value Unicode characters that are not implemented, including the emoji, etc. This is occasionally frustrating but we don’t want to limit users to one font that happens to include the right symbols. There are however user definable characters that could be created if we have the effort to maintain this, i.e. volunteers.
forkawesome is the icon font already used by zynthian! Great, now it looks much better.
However, the changing colors will be more difficult. While I can solve all the basic changes using a generic update like in the zynthian_wsleds_v5.py, there are some actions accessing and changing colours of particular button LEDs directly from the corresponding modules/screens. E.g. transport actions in audioplayer or patterneditor. I am afraid this will need much deeper changes of the current code. I will look for a solution requiring minimal possible intervention.
implementation of timing in zynthian_gui_base.py is probably completely unnecessary
I meant the methods cb_button_push and cb_button_release (lines 311-332 within the current revision on github), which implement their own timing
These are managed by the wsleds infrastructure. If you simply want to mimic the current V5 LED behavior you don’t need to do deep changes. Simply wrap the current mechanism. I few lines of code changed should be enough.
If you want to implement a new behaviour, it’s a different thing. But i think you should start mimicking current V5 buttons & LEDs. Once this is well implemented, we would figure the best way to improve things, all together!
Yes, I came to the same conclusion. Writing a simple fake Neopixel “driver” could make things possible without radical changes. Just to interconnect the two things. At the moment, it is a bit confusing that the numbers of the buttons do not correspond to the numbers of the LEDs, but that can be mapped. A more general abstraction unifying buttons and their LEDs would be ideal, but I don’t have such a big ambition at the moment.
Still need to find my way in the configuration system. And where to integrate the button widgets. I tried to add them to the zynthian_gui_base, but it looks like I should rather go up to the zynthian_gui (and/or the config) itself. Not as part of the control screens.
Well, so this really wasn’t that difficult (to write a fake wsleds “driver”). Now we have the colours replicating the original V5 LEDs behaviour on just 12-15 lines of trivial code.
The more challenging task is to integrate the thing into the current code and screen layouts. I have already spent a night and day fighting several oddities while moving the widgets to the root of the screen. Some of the existing screens just expect to have the whole screen for themselves. (And I suppose at least the touch calibration screen MUST use the whole screen in any case.) They use the full screen dimensions and freely reset the grid, which destroys the whole layout. At the moment, I only “tamed” the base and the confirm. Since I am not a power user of zynthian, I do not know all the screens and their purpose very well, so I cannot really test everything.
And then there is the configuration system. I suppose this configuration should have some name. It is basically a combination of a V5 profile with custom (partially fake) wiring. And I suppose a pure touchscreen variant without any physical encoders would also be interesting for some people. Personally, I use the names zynthian_gui_touchkeypad_v5.py and zynthian_wsleds_v5touch.py for the new modules/classes. But naming things and selecting colours is usually the most difficult task of the whole programming.
Colours on the real screen are brighter. Maybe a black background would fit the buttons better? It can also be configurable.
And yes. We could probably also add a more appropriate icon for the metronome. The icon font does not offer much better ones, but one could possibly add an image from the actual button. The colour changing might then be another challenge, though.
I am using the SVG directly through the cairosvg library. I would propose to have the python3-cairosvg library installed on Zynthian by default. It may be practical for flexible UI.
You may find the buttons are more obvious and readable if you changed their background colour rather than their text colour. I find the bright colours in your images rather difficult to read. There is already a carefully curted palette of colours used in zynpad that could be reused.
That switch is so deep! I really like them. The astetics. The glow. The option for flush or protruding. But they add so much depth to an enclosure that I avoid them.
I will look for a solution requiring minimal possible intervention.
