OK! We have a problem here. Let’s solve it
IMHO, first level should be the engine. Users shouldn’t need to know the extension used by every engine. Some engines have different types of presets (like ZynAddSubFX) and in such a case, a second level is needed for the different types/extensions.
But things are more complex yet … jejeje! Some presets are simple files, but some others are folders, like LV2 or PD patches.
So … we need a flexible format for preset folders. It depends of the engine …
Let’s do the webconf tool calls the zyngine classes (here we are getting closer of the core API approach )
Currently, each zyngine class implements functions for listing bank and presets. This is half the task.
We would need to add functions for deleting/renaming banks and presets, getting preset info and finally, creating a preset from a “bundle” (uploading presets).
In such a way, the webconf tool don’t need to worry about the implementation details of preset folders for every engine. Additionally, we can easily implement some kind of “preset info” feature, etc.
Finally, following this path we are getting closer to the core API approach.
What do you think?