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 