Pretty much what the title says. Being able to organize processor parameters with some kind of simple folder system would make navigating through the parameters of the more complex processors much faster and more performance friendly. For example, Drum Synth (every voice has many pages of parameters, a lot of them are identical), Helm (the filter alone has 3 or 4 pages) and Dexed (multiple pages of parameters for every operator, 6 identical operators) really benefit.Seriously, Drum Synth has I think 452 pages of parameters - even if they were all named in the most intuitive, descriptive way that’s just too much to scroll through live so it becomes a preset player instead of the deep percussion synthesizer it actually is, and it’s not the only processor that has this problem.
Instead of the static, flat list of parameter pages we have now, users could create and name “folders” in the list, add parameters or subfolders to them, and expand/collapse them. Similar to how signal flow between processors in a chain is already displayed as a tree.
So for example, Dexed’s operator parameters look more or less like this now:
Op1 EG Rate
Op1 EG Level
Op1 Dynamics
Op1 Pitch
Op1 KBL Scaling 1
Op1 KBL Scaling 2
Op2 EG Rate
Op2 EG Level
…
Op6 KBL Scaling 2
To get to the first page of Op6 parameters you have to scroll past 30 pages of parameters for op1-op5. If you’re in the middle of a performance, scrolling through all of those pages doesn’t just take time, it also (more importantly) takes more of your focus away from your playing.
With parameters organized in folders, we could have
Op1+
Op2+
Op3+
Op4+
Op5+
Op6-
├─EG+
├─Dynamics
├─Pitch
├─KBL Scaling-
├─KBL Scaling 1
├─KBL Scaling 2
In this case, to reach the first page of Op6 parameters would require scrolling past 5 folders instead of 30 pages, and clicking once to expand the Op6 folder. This would be much better in a performance environment and would also make sound design on the Zynthian native UI faster and more intuitive, without breaking any backward compatibility or anything.
User creation/naming/population of the folders would eventually be part of the native UI ideally, but in the beginning it could be as simple as a JSON-or-whatever file, i.e. for the Dexed example above the folder structure for one operator could be created as a plain text file stored in the same location as the processor’s presets, along the lines of
Op1 {
EG {
Op1 EG Rate
Op1 EG Level
}
Op1 Dynamics
Op1 Pitch
KBL Scaling {
Op1 KBL Scaling 1
Op1 KBL Scaling 2
}
}
If no file was present for a processor, it would default to the flat list we already have.
Native UI tools for creating this could be added later, i.e. an “add folder” function at the top of the parameter list, select an existing folder and bold-click to move, rename or delete the folder like the way the processor tree in a chain already works, and give parameter pages in the list a bold-click menu option to move them to a specific folder by name.
Even the most basic implementation of folders that required users to manually create JSON files and didn’t include any by default, would pretty much completely solve the “too many parameters” problem. It would be completely processor agnostic so once it was implemented it should just work with any new processors that were added. At worst, if the default names of parameter pages got changed in an update, those names might have to be updated manually in the corresponding folders JSON file (which the user could do themselves easily). Once the basic mechanics were implemented it should be completely hands-off from a development standpoint.
Apologies if something like this is already in discussion or development - I searched and didn’t find anything.