Custom UI ambitions, or maybe some day the controller grid page


Here I come again, after reading a lot of zynthian-UI code and thinking about it a bunch, and realizing this is a big task BUT I do have the experience to pull it off, I just need a deeper understanding of the codebase and to iron out some quirks and learn some stuff.

Maybe this could be a midiFX layer added on top of the synth, that has presets for the layers that you specify, this could simplify things a lot.

The main idea is to be able to make a “controller grid” page, a 2 by 8 (or X by Y) grid with the names (or abbreviated names) of parameters and their values, read a certain midi value for each parameter (regardless of the actual layer midi mappings), with the objective of being able to use 1 midi controller (think nanokontrol or launchcontrol XL) as more of a physical synth interface, by displaying in our already existing display what we would in a controller display (if that makes any sense)

If you’re not understanding me think of the faderfox ec4
Where the Zynthian takes on the upper part of the device, making an otherwise “dumb” and cheap midi controller with 8/16 controls into a potentially infinite number of them (4 pages might be enough).

Other points:

  • The midi channel of the controller grid page is attached to the midi channel of the layer used.
  • There can be more than 1 controller grid page for each layer(maybe switch between them with a specific cc?) the page stays as the last one accessed.
  • This might add unnecessary complexity (and it does) to anybody that does not use it, so making it adjustable either through the admin panel or webconf might be of interest.
  • some layers might not need it at all, so make it so that anybody could build their own(maybe a JSON file related to the layer).

Open a feature request I hear y’all screaming, but wait, I have my reasons not to (yet).

I think this feature is pretty huge, especially after reading some of the code and trying to understand the architecture behind the controller pages, so I don’t want to open such a wide, ambitious, and specific feature request without a PoC of this working in my computer with jack, Alsa and midi.

As so this post is to be used as a place to discuss the stupidity of this idea, the uselessness of such a feature and the many ways I have gotten it wrong, and also to help me along as I’m building this for DAAAAAAAM SURE as I’ve basically sold all my hardware synths and this is my only option.

PD: Huuuuuge missed oportunity with “Zyntherface” :zynface:


I want to understand…

Currently Zynthian displays 4 parameters at a time with each adjustable by one of the 4 rotary encoders. Are you suggesting displaying more than the four parameters with each adjustable by MIDI CC? So it would be the same as MIDI learn for all parameters of the selected engine (which is currently possible) plus a display that shows the values but not allow direct control from the Zynthian UI. (I guess we could add navigation and control from the UI as well as direct control from MIDI CC.)

If that is what you mean then I see it as a good idea. It is currently painful to edit parameters on Zynthian. By the time I have navigated through dozens of pages several times and eventually found that elusive parameter the artistic spark has gone and I am a programmer again! I want to grab a knob and twiddle.

Yes, very much that’s the idea, we “lose” the zynthian encoders for parameter manipulation, but we use that space for just displaying more parameters and maybe as you said midi learn. Maybe by using select and layer encoders as page up and page down button we could reduce the number of menus that one goes through before finding said parameter. (I know this is not in the ui design guidelines but i miss it so bad in the layer controls view)

What you just said is exactly the reason why I was thinking of buying a faderfox, but it’s expensive, it has no faders, and, by using the zynthian as the screen, we enable the use of multiple controllers with this features, making all synth parameters much more usable from an external controller.

This thread is a bit of a brainstorming one, I think that you do have something more concrete then I do in mind.

The hardware I’m gonna be using for this purpose is an original nanokontrol, and i would totally recommend it over the nanokontrol2 (particularly for the 4 layers and the extra knob and fader that you get)

If you bold-press SELECT you can then use the SELECT encoder to move the page selection up and down to select page which makes navigating pages of parameters faster.

There is already a precedent for using encoders to navigate a grid. This is implemented in the step sequencer so maybe there is scope to have a view that shows all the parameters of an engine in a grid which can be navigated with encoders (x/y) and adjusted with an encoder. I would like this view as most of the time I need to adjust one parameter. Also, the current layout of parameters means that if one wants to adjust two parameters simultaneously they may not be on the same page. It may be advantageous to allow the normal view of 4 controls per page to be configured by the user.

I know about the bold click on SELECT to go a page up but i find it counter intuitive and kinda cumbersome, I click once to go forward and have to click for long time + scroll to go back. I do not find as much use for the SNAP click ever really (this could be due to my own use case) so i wonder maybe using it as a previous page button would make more sense.

As I’ve been thinking about it it would be a grid of a set number of rows/columns (maybe set by the user).
It would divide into pages like it currently does, but what you said about navigation using encoders does sound like a nice option.

We could make this the default interface, having many more controls on each page. We could allow use to expose desired controllers on a, “performance” screen which acts like the current UI, 4 controls per page. This would change the current implementation to allow custom views counting the desired controllers.

Yeah, that would be great, and maybe this allows to finally sound design in the Zynthian without a computer or tablet.

I found another device that does something similar as what i was hinting at:
(the image is a link to their website)

Obviously i am not talking about the full feature set but the way it handles parameter setting, and the interface seem like a good inspiration

I am ready to get working into this feature but I find myself kinda lost in the mists of the github repo, and would really like to know i you @riban have something in mind that you could maybe explain to me what that would be and where i could start looking into this.

Zynthian GitHub has several repositories that each contain elements of the system. The one relevant to UI is which is cloned to the Zynthian at /zynthian/zynthian-ui.

Each screen / view is created with a Python class whose file is witihn the zyngui subdirectory. Screens are derived from a superclass, zynthian_gui_base. Most screens derive from a subclass called, zynthian_gui_selector which implements the list and controllers for rotary encoders. There are various calls made to these objects like refreshing screen, handling encoders and switches, etc. If you are looking for inspiration or example, you are probably best avoiding the step sequencer screens which use a more complex / unorthodox / dissident UI implementation which does not align with the wider ethos and whose implementation is likely to change.

We are in need of a coding style guide but try to infer style from existing code. (I struggle to do so due to long standing preferences but am getting there!)

The main application file is /zynthian/zynthian-ui/ I tend to test things by:

  • ssh to the Zynthian with X-forwarding: ssh -Y root@zynthian.local
  • stopping the zythian service: systemctl stop zynthian
  • Changing to the directory: cd /zynthian/zynthian-ui
  • Starting zynthian: ./

@jofemodo has told me that is suboptimal but it works for me.

I use keyboard bindings to drive it observing display on my local machine.

I have recently started using Geany (apt intall geany on Zynthian), a simple IDE.

If you are going to submit pull requests you will want to fork the repro then point your zynthian at your fork.

I am not traditionally a Python programmer so fairly new to it. (There are high-brow exchanges occasionally regarding programming languages - all in good jest. I prefer lower level stuff but Python allows fast coding, suitable for many purposes.) Feel free to ask more questions as you proceed. Be aware that just because we build it does not mean it will be acceptable to the project. If you want to avoid spending too long working on an ultimately rejected idea it is a good plan to garner opinion (like you are doing here) and an ounce of approval from the boss goes a long way :wink:. (I am not (nor no where near) the boss!) I tend to find my efforts appreciated but generally need to rework them when very good feedback and advice is provided. (I don’t always agree but it is wise to allow others to be wrong occasionally.)

Good luck.


Nice, that’s exactly the advice i was looking for! Thanks!

Yeah, I think I’ll tinker around the code today to try and understand it, and then draw some diagrams and sketches of how I think this could work, and post them here so everyone can voice their opinions (including Mr Bossman’s). I am aware that, without contribution guidelines and coding style it’s kinda risky but even if i have to live in a UI fork I can always call my fork Zyntherface and be a happy weirdo.

One of the seven Zynthian dwarves.

Or maybe 2 of them together?