How much do you adjust parameters in UI?

[riban]

Hi @ricard! Welcome to the forum and thanks for your feedback on experience with other devices. That all makes a lot of sense.

There are a couple of design ideas in flight that align with some of your thoughts:

• Display of multiple parameters on the same screen (more than 4) with ability to navigate between them and adjusts one at a time. This would give view of many more parameters but maybe have slower access. (Touchscreen can assist here.) I like the idea of being able to control multiple parameters, e.g. filter with left hand and resonance with right hand whilst holding the hold pedal with a foot to adjust a pedal note but this can be achieved with an external (MIDI) control panel.)
• A favourites control panel which holds a selection of parameters for different engines that a use wants fast access to, e.g. the parameters used during a performance. This might be integrated with the above idea.

Both ideas depart from the knob-per-control approach that Zynthian currently has but that is kind of what this thread is about - exploring what interface might be appropriate based on user’s actual workflows.

Your comment about Blofeld appearing to be the result of separate development efforts rang true - it is a common experience with software and evident in Zynthian (mostly my fault!) with new ideas being introduced without applying them globally. This kind of thing can occur during development of different ideas but it is good practice to consolidate design so that the user has a consistent experience. That is somewhere on our roadmap!

Zynthian presents all the parameters it has access to which is usually all the parameters of each engine but the arbitrary order is actually that presented by the upstream developer. There has been consideration in the past (which may be implemented with some of the ideas described here) to map parameters to a more appropriate / consistent / expected order. In particular, we should present common controls in consistent position, e.g. volume.

[ricard]

Thanks @riban for your welcome and reply!

To start at the end, exactly what governs the order in which the parameters are presented? My assumption on “arbitrary” was because I am naïvely assuming that the Zynthian basically takes the parameters in the order of some numerical ID, and assigns them 4 per page. So if the developer happened to group the parameters 4 by 4 this would result in a fairly logical arrangement of parameters, but I’m assuming that more often than not that would not be the case. But I honestly have no idea how the allocation actually works, it’s mostly based on my limited experience with LADSPA which uses numerical parameter IDs.

I’m thinking that it sounds fairly straightforward to have a mapping file that maps engine parameters into groups of 4? Although it’s a bit tedious to write such a file, it only needs to be done once per engine. And as a user one can change the mapping as wanted. I think it would be a simple yet effective step to get a better organized UI.

Regarding displaying multiple parameters at a time, perhaps it’s a personal preference, but I think I’d rather have fast navigation among a series of well defined parameter pages, rather than have a several parameters available at the same time - given the screen size of the Zynthian the text would be rather small if enough parameters are to be displayed to be useful.

A synth I didn’t mention above is the Audiothingies P6 (now in its third incarnation as the MicroMonsta 2). Given the restriction of a fairly small (in terms of number of characters) display, being able to jump quickly between parameter menus using the 9 buttons makes for fairly snappy editing. I really like that UI for that reason.

I don’t know what the (fairly newly introduced?) buttons below the screen are for, but I’m sortof thinking something along a similar line of using the buttons to quickly reach parameter menus. Using one- and two-button combinations, more than 4 pages could be reached quickly. But perhaps such ‘chording’ of buttons convolutes the interface too much.

Alternatively, using the central area of the display to display a block schematic of the synth, using the touch feature to navigate to the different modules/parameter groups. But I think the space is too small to show anything but a really basic synth in that manner if it is to be successfully navigated using touch control.

EDIT: Having perused the available engines, I’m realizing that the above mostly pertains to fairly simple engines with few parameters, such as the TAL NoiseMaker. Especially instruments like Surge or Helm, with their dynamically created mod matrix, would require a huge number of parameter pages in order to access all available parameters, and it would be rather hard to grasp. Even ZynAddSubFx would be hard to get ones head around without the associated graphics.

I should relate another synth I have, the E-Mu XL-7 Command Station. It’s really a sort of groovebox, but leaving the sequencer etc aside, the synth section can be edited using a matrix of 4x4 knobs. In this machine, instead of directly mapping parameters to knobs, the knobs output CC values which can then be connected to any parameter using the mod matrix. There are printed legends for all knobs such as “cutoff”, “resonance”, “filter attack” etc, but they are only suggestions, nevertheless, they are adhered to by the factory presets. I’m not really sure this is the best design, partly because when used to the full it eats up 16 of the 24 available mod matrix slots, leaving precious few slots for the ‘real’ modulation paths.

In a potential Zynthian guise, perhaps one could have a configuration file, which specifies an offset from the preset value of a certain number of parameters (most naturally 4, but perhaps 4 pages of 4 using the push buttons). E.g. knob #1 could be set up to adjust the filter frequency by +/- 50 steps from the pre-set value for that parameter. A UI to graphically select the appropriate mapping would be appreciated of course.

Another synth (well, groovebox, actually) with a similar approach is the Novation Circuit. It has 8 encoders which in certain modes are assigned as 8 “macros”, each of which can control up to 4 parameters simultaneously in the synth, with selectable center value, range, and offset for each parameter. So, for instance, one knob could be set up to control the filter frequency, and at the same time when turned up past half way, lengthen the filter decay time. This way a single knob can have a rather varied set of functions associated with it. The downside is of course that each “macro” must be individually programmed when setting up the patch. In the Circuit patch editor, this is done in a dedicated part of the UI.

[Jerryn]

I adjust parameters all the time to dial in the sound.

[pac_71]

The Karma engine takes an interesting approach to parameters. Given limited real-time controls on synths like Kronos/M3, it applies consistent RTC (real-time control) models depending on the type of GE (bass, lead, drum, etc). GE is the generated (midi) effect which contains the specific Karma settings for a patch.

From the wiki. Other goals of the RTC Model Concept:

• All sliders and switches should do something fairly obvious.
• There should be standardization between RTC Models as much as possible.
• Loading GEs should be possible for the user in a way that guarantees they sound great and are all set up for useful operation without really having to know too much.

[riban]

@ricard

LADSPA which uses numerical parameter IDs

Yep - that is how LV2 works. Developer adds parameters, gives each a unique (integer) ID and Zynthian uses these, in order, in groups of 4.

@ricard

screen size of the Zynthian

The suggested enhancement is to allow better use of larger screens. The 3.5" standard screen lends itself less effectively to this.

@ricard

buttons below the screen

These can be configured to trigger CUIA, API actions, e.g. navigate to a screen, panic, program change, etc. By default they send program change. They do not (currently) support simultaneous multiple button modifier type operation. It is quite a good idea to add a modifier button, like a shift key.

@ricard

block schematic of the synth

I have been considering something similar. It may be challenging and would require each engine to have its own config.

[wyleu]

@ricard

I’m thinking that it sounds fairly straightforward to have a mapping file that maps engine parameters into groups of 4? Although it’s a bit tedious to write such a file,

Yes That is the problem really.

The zynthian at root is a bit of code (sorry jofe,riban et al . . .) and an awful lot of mappings.
The GUI simply becomes the interface to those mappings right across the object model.

I’d rather have fast navigation among a series of well defined parameter pages, rather than have a several parameters available at the same time

Favourites really…

The problem with mappings is as you say someone has to define the initial order or you end up with chaos. Where is the Attack parameter for the Filter envelope if it’s there at all. . . ?
And more importantly where is the overall volume (gain??) control for the engine we have enthusiastically added and does it go from 0 - 100 or is it a gain of 1.000000? so that we can send CC No 7 (vol) so we can set up the default for an overall volume control for that layer…

Mappings upon mappings all the way down.

You want to find it once and then pull it up in your favoured display for that engine and probably ignore all the others EXCEPT when you are selection ordering mode.

Now should that be a GUI facility ( I like this parameter stick in on my favourites : possibly a Bold press somewhere) with the favourites/edit selection or in the webconf where we have the same issues but a much larger canvas to perform the edit.

[riban]

There has been a lot of solutionising (not a real word) here which I specifically wanted to avoid at this stage. It is all good and useful stuff but what I wanted to understand was how much users currently adjust parameters, why and how much they may prefer to adjust parameters.

I think we generally want to be able to get to any parameter but not necessarily all the parameters. Adjustment of parameters is a popular feature during sound design and performance. Current access is sub-optimal due to ordering and navigation but the ability to assign a knob per control is advantageous rather than navigating a list of parameters to adjust with one knob. It is clear that most users want to be able to create a custom view of controls to present just what they need for their workflow hence more customisation in the configuration. This may mean that default order is less important but ability to cusomtise becomes important.

[ricard]

@riban

There has been a lot of solutionising (not a real word) here which I specifically wanted to avoid at this stage. It is all good and useful stuff but what I wanted to understand was how much users currently adjust parameters, why and how much they may prefer to adjust parameters.

Yeah, it’s very easy to slip into problem solving mode when discussing this type of thing.

I don’t really want to bog this thread down with my own views, but I have thought a lot about parameter editing over the years, and which compromises are better and which are less good.

For instance, on the Prophet 5 and Nord Lead 1/2/2X, all the mod routings and waveforms are displayed using LEDs on the panel, whereas the continuous parameters are handled with knobs so you can’t see the values. For me, this means that at a quick glance I can see the architecture of a patch, even if I can’t see the actual parameter values. So even if these machines have a fairly old UI, the use of LEDs to display switched values is actually a great idea in terms of user feedback.

In contrast, I had a Nord Lead A1 once, and in that machine, there is a single modulation envelope, where separate continuous controls control the amount of envelope fed to the oscillator and filter, respectively. This means that I cannot tell at a glance what is actually being modulated by the envelope. It’s a small detail, but convolutes the synth for me. There is also a feature whereby one can read the current value of a parameter, by pressing a button and turning the corresponding knob, but it’s a two-hand operation and thus rather clumsy. This would not be an issue on the Zynthian, as there’s a display to display values, but I’m just trying to relate how important that type of feedback is, IMHO.

Another two-hand operation on the A1 is, IIRC, setting the filter keyboard tracking. This means that I cannot play the synth while adjusting the keyboard tracking. Again, this makes the UI less accessible.

The Audiothingies P6, with it’s rigid layout of a number of more or less directly accessible parameter pages (some require multiple presses), and character display, doesn’t look too sexy, but it’s very appealing to me in terms of accessibility. Few things require two hands, and the interface paradigm is quick to learn, making the synth inviting to edit. Then again, the architecture lends itself towards this type of UI; if there were ten times more parameters, the matrix of parameter selectoin buttons would be daunting.

One thing that I appreciate about the Blofeld is the way the envelopes are displayed graphically. Even if they don’t show a scale representation of the actual envelope, they do give a quick visible feedback of the envelope shape. The Blofeld uses the graphics to display the filter response too, as well as the oscillator and LFO waveforms and frequencies.

I think we generally want to be able to get to any parameter but not necessarily all the parameters. Adjustment of parameters is a popular feature during sound design and performance. Current access is sub-optimal due to ordering and navigation but the ability to assign a knob per control is advantageous rather than navigating a list of parameters to adjust with one knob. It is clear that most users want to be able to create a custom view of controls to present just what they need for their workflow hence more customisation in the configuration. This may mean that default order is less important but ability to cusomtise becomes important.

I think that sums it up rather well.

I think synth UIs are a very personal thing. For me, the ability to quickly navigate between parameter pages, preferably without having to scroll through lists of things, is key. I’d rather have to press a slightly convoluted combination of buttons to get where I want to go, than have to look at the display, see what page is up, and press a button a certain number of times depending on what page was actually up, or have to scroll through lists.

Speaking of which, the accessibility of lists can depend very much on the encoder response. For instance, the Blofeld uses its stepless encoders for selecting stepped parameters like mod matrix slots or waveforms, in contrast to the Akai Miniak which has a very clicky encoder which is much better for that type of operation, as it’s easy to look at the display, think “I need to move three steps down”, and turn the encoder three clicks, rather than having to constantly stare at the display to see when one has moved exactly three steps down. A small detail, I know.

I’m not really fond of macros or maps of subsets of parameters, because it always seems like I’ll soon need to access something that is not available. On my Circuit, which I use mainly for blippy sequencer-type sounds, I’ve created a patch where I’ve set up the 8 knobs to access enough parameters to create a reasonably wide range of sounds in that domain, in effect, creating a synth within a synth. It works well, but only because I’ve purposely decided to see the instrument (or at least that patch) as a small synth with only few parameters, sortof like an Electribe EA-1. So it’s certainly useful to be able to do things like that, but it requires the extra step of designing that synth-within-a-synth first.

I feel I’ve taken enough space in this thread with these random thoughts. Over to someone else.

[riban]

@ricard

graphics to display the filter response

I briefly considered how I might include a filter editing widget I designed for another project but soon realised it would be like forcing a square peg into a round hole… We should use the synth engines’ own GUI to perform complex sound design, especially for complex synths like Helm. We can expose pretty much any control of any synth to the Zynthian physical UI and external controllers but every engine is different which means we need a generic approach which does not lend itself to the complexities of detailed sound design. A small synth might be completely configurable from the Zynthian UI but you have very little chance of even remembering where you are when navigating the larger ones.

I think that is a fundamental realisation for me - that the Zynthian UI with itts relatively small screen, four knobs and multiple engines is not completely configurable from the front panel and that there needs to be access to the engine’s GUIs for full control but that access to a customised selection of parameters does allow significant sound design and performance control from the UI / external controllers.

@ricard

“macros”, each of which can control up to 4 parameters simultaneously

This is already implemented in Zynthian to some extent in that you can assign each MIDI CC to multiple controls but the enhancement that I would love to see which would allow better implementation of thta macro feature is to allow offsets to be configured, i.e. that a CC adjusts the control relative to its current value, not absolute - adding or subtracting rather than jumping to the new value. The thing you said about having ranges of application is also good - it would only affect a change within a define range but there are some complexities to consider… a future development. This is certainly a big issue I have with control - I have an analogue modelling synth sounding great and want to modulate the cutoff frequency. As soon as I move the exrpression pedal / knob on my external MIDI device the cutoff jumps and it ruins the sound / vibe. To drag myself back on topic - it is a significant reason why I don’t use MIDI mapping as much as I would like. I would especially like to modulate parameters from aftertouch but this suffers the same problem.

That previous point highlights a reason why we need access to all of an engine’s parameters. We each want to modulate different parameters and hence need a mechanism for mapping CC to controls. The current method involves finding the parameter in the engine’s control screens, turning on MIDI learn and twiddling the knob. There are different implementations as described in this thread but the point is that a curated list of controls or better, a user defined selection of controls may be preferable for sound design and performance but full access is required to perform the mapping and ideally that is done without the need for external devices like VNC.

I find it tricky to decide which parameters to map to CC (partly due to reasons described here). Maybe I need to play with the engine’s GUI for a while to do sound design to identify the controls I need to access within the Zynthian UI. It is certainly tricky to do so directly from the Zynthian without understanding the engine.

[Pastitas]

@riban

That previous point highlights a reason why we need access to all of an engine’s parameters. We each want to modulate different parameters and hence need a mechanism for mapping CC to controls. The current method involves finding the parameter in the engine’s control screens, turning on MIDI learn and twiddling the knob. There are different implementations as described in this thread but the point is that a curated list of controls or better, a user defined selection of controls may be preferable for sound design and performance but full access is required to perform the mapping and ideally that is done without the need for external devices like VNC.

I think having to use the webconf for the arragement of the controls wouldn’t be a huge pain but definitely there is a need to be able to map cc in the device itself.

In my opinion the way the current method is flawed is in the workflow with mapping midi in the synths, with no way of exporting, importing or modifying midi mappings for synths, which kinda locks you to using snapshots for the purpose of controller maps, even if you purpose-built midi interfaces for the synths you most often use.

Also for me the part where you get feedback into which value you’re modifying with an external controller is pretty important.

@ricard

I don’t really want to bog this thread down with my own views, but I have thought a lot about parameter editing over the years, and which compromises are better and which are less good.

I’d recommend you to check out this thread (shameless plug) then, since I’d also love some feedback on the idea I’m working on and talk about user interface desing.

[jofemodo]

Check this new feature:

LV2 Controllers Groups

Hi @zynthianers! Good news! I’ve just implemented “LV2 Port Groups”, a LV2 extension that allows to group the controllers and other ports in a convenient way. It’s not very extended yet, so there is only a few plugins that currently have groups defined. You can try with the V1 series: synthv1 samplv1 padthv1 drumkv1 Probably there are more plugins, so please, send feedback if you find more. Anyway, we can add the “group info” to the plugins we want. Currently it must be done by hand, but…

Enjoy!

[ricard]

Now that I’ve actually got a Zynthian and have had time to play with it a bit, I’m sortof feeling that the current UI with four-parameter pages goes a long way for synths with a reasonably small and standard architecture, like NoizeMak3r. But when you hit instruments like Dexed or ZynAddSubFX, editing them via a small screen is just going to be painful, unless you want simple global controls like global cutoff frequency, or an offset for the release time of all the envelopes.

Having played with ZynaAddSubFX for a while, I think it’s going to be very hard to get something in a small box that will ever approach the overview you get with the Zyn-Fusion UI. There’s just way too many parameters. In that case, having a separate screen/laptop/tablet is the way to go as far as I’m concerned. In fact, I got a ten year old tablet computer primarily to use as a UI for ZynAddSubFX. With it’s 12" touch screen, I get fairly direct control over the parameters coupled with the overview that comes with the GUI. Setting up a subset of parameters for on-Zynthian-editing or trying to navigate through what would surely be hundreds of pages is just going to be too painful. I honestly feel that trying to create a useful subset of a large number of synth parameters is just going to leave you wanting for the ones that didn’t make it into that subset.

[Pastitas]

You can access the actual UI running in the device via the VNC web viewer function in webconf

[ricard]

Yes, I know, but that seems more of a temporary option. At least when I’ve tried it, it’s been rather slow, and the zyn-fusion UI takes quite a lot of CPU power. It’s certainly good that it’s there, to accomplish things that otherwise can’t be accomplished, but it seems cumbersome for everyday use.

[riban]

This is exactly what I wanted to discuss. @ricard explains how awkward it is to do sound design within the small screen / 4 knob environment and that the knobs become occasional use adjustment or a few performance adjustments. @Pastitas explains access to full GUI for sound design which, within the constraints of the current design (hardware and firmware) seems like the best way to perform detailed or complex sound design. One might imagine that the naitive GUI is likely to be the optimal method of sound design, especially with a complex synth with layers of parameters.

I would like to see an interface that increases the time you can perform sound design before needing to resort to the naitive GUI. I would also like to have simpler access to the naitve GUI, e.g. via HDMI and easier way to enable / disable it to save resources for performance - but I err into that territory I wanted to avoid - designing the device.

I find the inconsistency of parameter position to be a barrier - if they are for performance tweaks then parameters common accross engines placed in consistent postions would imporve my experience of knob usage.

I find it difficult to locate parameters during sound design. Recent change to group them has improved this but I still find myself squinting at the screen, reading each parameter on each page and not finding what I am looking for. Maybe a splash of colour might help here. Some hardware synths use colour or other methods to highlight different functions, e.g. envelope section, filter section, etc.

I often expect the push switch within the encoder to act as a parameter switch, e.g. to toggle a parameter. This makes the use of knobs less intuitive. Combined with this I struggle with navigation. I often stab at buttons in the hope that it will take me where I want and find myself in a foriegn land, bewildered. This monkey testing approach can often expose bugs which then distract me from the art.

My early designs for DIY Zynthian had lots of knobs and switches to allow assignment to lots of parameters. I shelved that whilst I got to know Zynthian. Now we are so intimate I see that the 4 knob design could be good for most performance and an external controller with lots more controls could benefit sound design. I think a smaller external controller may benefit some perofrmance too. I think more flexibiity in displaying parameters would benefit this, e.g. pages with lots of values, not mapped directly to the 4 knobs but controlled via external controller would improve sound design workflows.

[ricard]

One thing I must say is that the existing 4-parameter-at-a-time is excellently implemented. The way the graphics go from color to grey when SELECT is clicked clearly indicates that the UI is in parameter select mode, and it’s great that it actually shows the parameters and their values as the pages are scrolled through, and the response is quick so it’s easy to navigate through the pages. Even with an engine like NoizeMak3r where the parameter pages are just labeled CTRL#1, CTRL#2 etc, I find it’s easy to find the parameter I’m looking for.

For me, I think scrolling through pages on the Zynthian which map to an external controller would be very much less intuitive. The mental distance between the Zynthian display and the external controller knobs woud make it a cumbersome solution. In that case, it would be better to have an external controller with a display so the same directness could be achieved as with the Zynthian.

What would be interesting to test would be to use an external controller with a display, such as the Novation Zero SL, and have the Zynthian control the device completely, including the display, so that it doesn’t have to be set up manually.

[riban]

The parameter navigation @ricard describes is a recent addition which may have been viewed as slightly controversial. Indeed it takes some getting used to the change in behaviour, especially when the old behaviour remains for engines with fewer than four screens of controls. It is good to hear this enhancement is working well. It was thoughtfully implemented, thanks @jofemodo.

The Novation Zero looks an interesting device. It would take some serious hacking to get it fully integrated with Zynthian - something I would love to do if I had a Zero and the time to spare!!! I wonder how well it works with one display unit above several controls? I have long wanted a hardware controller with knobs and switches adjacent to display that showed each control’s purpose and value. (Indeed my workbench is littered with the components to build such a device - again, where is the time?)

[stewart]

@riban @ricard I think you would find it interesting to check out the work of one of our local synth gurus Claude Woodward (aka “The Sonic Manipulator”). He is one of those synth players that eschews the whole idea of presets, and prefers instead to manipulate all of the synth parameters on the fly as he is playing. For those with a background in analog synths this is a very natural approach, since the original synth keyboards were exactly like this. But it is also essential if you are interested in playing expressively, and achieving very fluid sound design. In the age of digital synths this means that you have to design your own controllers. There is nothing commercially available that will adequately do this.

This video shows one of his older designs. Claude’s current designs offer over 100 MIDI parameters that can be smoothly manipulated via control wheels, switches, soft-pots and breath controllers. The value of a control is indicated by changing its colour. As for the purpose of the control, this is somewhat down to memory, but the controls are laid out like a keyboard so as a mnemonic device you can relate a control to a note of the scale. This works a bit like the “method of loci” or “memory palace”, a well-known technique which dates back to beyond the ancient Romans and Greeks.

The MIDI Control Monster

More information is here: http://sonicmanipulations.com

Disclaimer: I am also somewhat involved in the design of these controllers, so feel free to ask me any questions.

[riban]

Nice! My memory palace is in ruins like it was built by the ancient Romans or Greeks!