@Lindon said in Custom browser - custom preset file format???:
@Orvillain this all seems massively complicated for preset saving and loading, what does the existing prest management and a custom tag based browser on the front of it not give you?
Ultimately it isn't just about preset saving and loading.
They want full customization of the preset data model. They want each preset to have an associated image. They want to be able to import and export presets along with sample content at the same time. Which means I need full path control over the samples when saving. They want rich meta-data based browsing and on the fly searching. When saving a preset, they want to be able to specify various tags and descriptors, and it makes sense to store that stuff directly into the xml. There's probably more they want, but off the top of my head that's all I remember.
Everything they're asking for seems to involve deeper control over the load and save mechanics. But it's actually not that complicated. I'm essentially overriding the HISE automatic system, with a manual system. I'm capturing nearly everything that HISE captures automatically in a single call to UserPresetHandler.createObjectForSaveInPresetComponents() - everything else is custom.
Unless I'm missing something, there's a lot that the stock preset management system doesn't give you.
After spending a fair amount of time trying things out and reading the API, I'm fairly sure I have a decent grasp of how it all works now. There are also pre and post callbacks for loading and there's a post callback for saving too, which I'm going to need to tell the system to refresh the list of presets; or to update the external database, which is probably going to be required too.
