there has been lots of discussion on this, and in calls Ive had with @johannes we have discussed it a couple of times.
we see areas if improvements needed, and also heard the requests,
so far thoughts are..
- keep the existing approach (as its really flexible, and powerful) , but add an additional 'snapshot' style as well which saves all parameters (so more like a vst). (might ditch the term preset, so we can get a clear new terminology)
- save/load 'presets'
- all parameters types stored/recalled
- make UI more intuitive.
as has been pointed out, we need to be careful of both code size, data size, and time take to load... and also being careful of 'sound glitching', also its not like vsts which tend to just be for recall, but also the current system is more a 'performance' tool, which is why we don't want to replace it, but supplement it.
actually, the more you think about it, the more 'considerations' there are... some less obvious than others.
e.g. we have to bare in mind, for many no computer is attached, rather a controller... or there might not be an sdcard?
the other side to this, is this is dependent on the (fairly major) changes which we have discussed (in dev section) to parameters. these changes need to be done before (or alongside) the 'preset' changes as there is a dependancy.
what would be interesting is to hear users thoughts on 'use case' for parameters...
how do you actually use them?, beyond simple save and recall?
(this is probably more useful than UI representations, or low level details, which is all subject to change)
of course, we have to be realistic with expectations, all the above takes time to develop, and we have to do it at a pace that doesn't introduce a huge number of bugs. no one wants a hugely flexible system that crashes or is erratic!