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

Yes up to a point. A sort of favourite selection. Perhaps this could be number of touches of a control which could be overridden by user choice? So a couple of visits to the far off reverb encoder brings it up in the favourites selection? where it should join overall volume as the highest index in the dsort order :smiley:

Just watch out or encoder noise if connected to a zynaptik or similar MIDI CC generating device.

Sounds like an idea worth exploringā€¦ in the future!

I like the idea of a grid of small controls that allows indirect but rapid access to more than 4 controls per page. The mock-ups that @Pastitas had done look good. That differs from having a page with just 4 user-configurable controllers or 4 most-frequently-used controllers. These are different solutions to similar problems.

The grid of controls is good for seeing a lot of parameters and rapidly (but not instantly) controlling those parameters. It gives a better interface to parameters from an external controller. These are all really useful enhancements.

The direct access from 4 encoders provides rapid access to fewer parameters directly from the Zynthian hardware interface which may provide a more useful user interface for performance when a user does not have (sufficient) external control. I am not sure whether @wyleuā€™s idea of such a direct access screen learning what you might want (from frequency of use) would necessarily translate to good user experience. Although I adjusted the filter cutoff 12 times today - it is done and I am happy with it so donā€™t need it again but that resonance control has been bumped off so where has it goneā€¦

The grid of controllers workflow may use (up to 4) encoders:

  • Move selection cursor horizontally (possibly wrapping at end of row / screen)
  • Move selection cursor vertically (possibly wrapping at end of column / screen)
  • Adjust selected value
  • Spare

and encoder push switches (not necessarily all and maybe with modifiers like bold press):

  • Exit screen
  • Access menu (maybe?)
  • Toggle value (if appropriate)
  • Go to corresponding engineā€™s control screen
  • Reset to default
  • Select different parameter to adjust
  • Change labels

Actually some of those functions may best be implemented via a menu system (similar to used in sequencer).

I really like this idea and am happy to help you develop it.

1 Like

Itā€™s very much at the threshold of usability. What started as the few controls wrapped round the sf2 sample format has quickly expanded into many, many parameters on an increasingly wide range of engine objects.

In truth sound editing is the fast and efficient selection of these parameters, so preview and access is very important part of the build process of a sound, I want to be able to get to the decay time on a filter thatā€™s many pages away to reduce it or lengthen it.

To make that process qucik I need categories to allow me to quickly get to ā€˜A filter type objectā€™ and a ā€˜time constant typeā€™ thing with in it.

The normal approach is methodical categorization but this quickly fades as itā€™s more of a librarian function that actively creative. The irony is the screen for construction needs access to as many parameters as possible whilst the screen for performance requires as few controls as possible. Weā€™ve consciously limited ourselves to four active controls and so we want to make best use of them. But, this must be entirely under the ultimate control of the user.
I think this is also related to basic zynthian functionality. The basic functions one would find on a mixer would seem to be initial defaults, Engine Volume, Engine Pan , Engine routing, but these should be easily ( but not clumsily) overwritten, so a restore to default or last known sensible point would seem to be a must.

Visibility of which parameters are available is a categrisation issue, so ā€˜somebodyā€™ needs to say this is a filter parameter. It doesnā€™t need to be massively precise but something that breaks down into the basic synth functional blocks (OSC, Filter, AMP Delay, LFO, Sample etc) would go a long way to accelerating that process.

Presumably itā€™s really Turtle, graph like construction of groupings. The clever bit would be minimizing the difficulty of a specifc user declaring a category and the efficient and speedy propagation of that declaration throughout the community.

or Git for parameters :smiley:

The 1010music Bluebox (Bluebox ā€“ Compact Digital Mixer/Recorder - 1010music LLC) uses a nice way of controlling more than four variables with 4 rotary switches: it shows them as blocks of four, which can be selected with a switch button or the touch screen and the 4 rotary encoders are then assigned to the four in that block of four.

I love that bluebox, it looks like a very nice recording/mixing tool.

I went looking for some code for this but your github page does not contain any yet. I would love to see this progress. Any chance of uploading what you have done already (to create the bitmaps)?

Hi there, sorry for a too long silence on this topic, Itā€™s been a crazy week and Iā€™ve not had any time to neither work on this nor respond to the thread, so this is gonna be a long one.

This could be a huge step forward, as right now Iā€™m just trying to wrap my head around the current screen system and the data structures behind it. My idea right now is to generate a controller_grid array with the structure described in a __cg.json file generated with some kind of editor, so that the pages and controls are arranged in a user-definable manner, and have it be an alternative view option that can either be the default one (admin option menu) or can be activated per layer (layer option menu) and substitutes the current controller screens with the 4 controls.

I like the idea of a grid of small controls that allows indirect but rapid access to more than 4 controls per page. The mock-ups that @Pastitas had done look good. That differs from having a page with just 4 user-configurable controllers or 4 most-frequently-used controllers. These are different solutions to similar problems.

The grid of controls is good for seeing a lot of parameters and rapidly (but not instantly) controlling those parameters. It gives a better interface to parameters from an external controller. These are all really useful enhancements.

Thatā€™s exactly the point, plus the fact that mapping to external midi controllers would be done for all pages (or tabs, as they are shown), in other words, one mapping in a midi controller can control everything in the current page, and changing pages changes the available parameters without having to change anything in the midi controller. You can see it this way: the screen shows what your controller can change.

The direct access from 4 encoders provides rapid access to fewer parameters directly from the Zynthian hardware interface which may provide a more useful user interface for performance when a user does not have (sufficient) external control. I am not sure whether @wyleuā€™s idea of such a direct access screen learning what you might want (from frequency of use) would necessarily translate to good user experience. Although I adjusted the filter cutoff 12 times today - it is done and I am happy with it so donā€™t need it again but that resonance control has been bumped off so where has it goneā€¦

The ability to use zynthian standalone is something Iā€™d very much like to keep, and this

seems to be exactly the kind of navigation controls Iā€™d like. Straightforward and without need for notes or learning.

This is something Iā€™d really like to ponder on, as, and I mean this with the utmost respect, the current general UI flows and encoder button functions seem a bit odd to me, and donā€™t really feel intuitive or context-based. I think this is a result of the fact that this project has grown to be waaaaay bigger and more capable than the first iterations and UI designs counted on, so this is not just hating, Iā€™m looking up some UI design guidelines and best practices to try and propose a more intuitive solution.

In terms of what youā€™re proposing Iā€™m generally in line with you, Iā€™d like to talk about it with you to come up with a proper flowchart if possible.

Iā€™m really really happy to hear this as Iā€™d gladly take all the help I can (especially coming from such a veteran!)

I think this stems from the fact that zynthian, as the name implies, had one synth engine in mind while initially designed, and, as the deeper integration of zynaddsubfx and linuxsampler show, the ordering of parameters is something thatā€™s valued.

Regarding ordering of parameters in pages as they work now i think that categorization or doing sections (kinda like what you see on hardware synths) would be a huuuuge think to make things useable, with names that make sense and categories that help you understand things at a glance.

I was looking a bit into this categorization of the parameters and then this idea of a bigger grid popped into my head, but still i think the lv2 parameters from most plugins need a lot of work and pull requests to make them use-able. Having said that somebody here tried something along those lines in this post

So this is something thatā€™s still helpful for my solution, albeit not necesary as you should be able to tag(or name) things as you want (pages, controls, options within a control)

I agree that TkInter is not the nicest of GUI toolkits but it also isnā€™t the worst and if those screenshots of yours were created with TkInter then you have done a good job of shaping it into smart controls that take on the feel of Zynthian. I can help to integrate such screens into the Zynthian infrastructure but a bigger challenge is how they interface with engines.

I have thought about this a bit recently and propose that the API be expanded to support this. Each engineā€™s control could be exposed to the API with bi-directional control. Each control could present its type, min/max/enumerated values, label, etc. to the API and be controlled via the API. Each engineā€™s control could be presented as a path, maybe based on its layer / type (although maybe type could just be a parameter rather than part of the API path).

This would allow query and control of each parameter. The API could provide enough information about the layers to allow external devices, e.g. OSC UI apps to auto-configure. For the use case discussed here, the API could be used with some optimisation to allow direct connection between the screen and the engine (or at least minimise abstraction).

I quite like the idea of using the API as an abstraction layer where all controls are available. It allows for simple / complex interfaces to be designed with a consistent technical interface. It may appear as additional code and complexity which may have detrimental impact on performance but if designed carefully it may prove to be no worse than the current UI implementation. (ā€œNo worseā€ isnā€™t a bad measure of success!)

I will try to introduce the idea at Club tonight and see if anyone is particularly interested. They may not care about how it is implemented but may have ideas of where it may be used and hence influnece design.

Regarding current workflows - you are right to challenge them (as have I with some of the UI mechanisms I have introduced with the step sequencer) but we do have a hardware device which we need to make work with all UI designs. I am very much aligned with your goal of providing visual feedback to external control knobs but feel we should also allow control of those controls from the Zynthian UI and try to maintain a degree of consistent behaviour. As we move forward that behaviour may change as we learn better ways of utilising the available control and feedback in which case such learnings and changes in workflow should be ported to existing modules. Indeed we may find that this work with API abstraction may allow a rebuild of many (all?) of the UI screens which may automatically inherit such workflows from common base classes.

1 Like

If I understand you well enough, having an API separate the UI code from the system codebase and engines would be a huge improvement in terms of modularity, with every good perk that modularity brings to the table. Iā€™d really appreciate something like being able to poll an engine for controls and things of this nature, Iā€™m not overly concerned about the ā€œadded code and complexityā€ as Itā€™s my opinion that arquitecture changes such as this actually simplify everything down. (And let me tell you, itā€™s really fricking hard to get your head around how it works right now).

Having to peel out the layers to figure something out is always worse than having a set of interacting modules that are somewhat standalone. Creating a new engine, GUI or even module would be easier with this paradigm.

In a complex multi-pane GUI, customizing it to group the most important ā€œto youā€ controls might improve productivity.

Short of that, a layout option to Sort by Last Used, (which would completely break the memorize by location physical control metaphore), in some use cases, the hottest 4 parameters you are currently tuning would be right there in the first page.
Perhaps a duplicates of the last 4 controls used, could be an optional first page.

Okay, a month has passed, and this has become Itā€™s own thing in terms of how much time it requires from me (which I donā€™t have) soooo Iā€™ve commisioned it. In about a monthā€™s time Iā€™m gonna have a python developer join me in this efforts, hereā€™s hoping we can get something working!

Hello,

I just came across the zynthian project about a week ago and find it very interesting - also since Iā€™m looking for a possibility to run Pianoteq on a Raspi. Since I am a developer, I started to read this post and also checked the source code on Github.

I think the Controller Grid UI idea sounds great. One idea came to my mind: couldnā€™t one also use the touch screen to select the control which should be edited, this would save the two X/Y encoders and one could have 3 encoders for parameters (and the one for Z pages).

In addition, one could keep editable parameters split over pages if wanted (meaning you select encoder 1 for option A on page 1, go to page 2 and select encoder 2 for option B and still control option A (maybe showing an overlay of this option and the value for visual feedback).

One suggestion would be to add a category list to each parameters, which could enable an automatic grouping of parameters to form pages based on the category (eg. OSC, Filter, Env for typical synth). By adding user editable categorizes and allow for one than more per parameter, one could support user defined pages and also the Sort by Last Used, where some further logic would automatically adjust which parameters appear in this category and then list.

I am sure, discussing and drafting a good design pattern that supports seperation of UI, parameters and control is helpful as a first start.
I read you have already found a developer to dig into this, but if you need more help, I would be willing to assist. I am not a Python pro, but acutally did lots of object orientate C++ and C# programming and too much of C coding for microcontrollers :wink:

Hi @0penSourceFreedom and welcome! The touchscreen is a secondary input device and some custom builds dispense with this option so we want to keep the interface fully drivable from the encoders.

Okay, then it makes perfect sense to use encoders for X/Y/Z. My idea could only be something optional if touchscreen is available and the user wants this behaviour.

This would still very much apply, and is a part of the solution thatā€™s being considerated as of right now.

In the coming months development for this feature will provide a PoC with working ui elements and some midi translation aswell. Iā€™m hoping that after said test we can work together to integrate it into the zynthian

That sounds good :slight_smile: I am already looking forward to further updates of the first tests then!