Hi guys,
I’m working on a new presets system. So far I’ve used XML files and I prefer to avoid ValueTree. Most of the management, until now, was done on the UI, with a presetMenu class scanning the presets folder every time the popup is shown. I was using this since 2014 without any major issues, but now I need something better.
What I’m trying to to right now, is to have a manager as a member of my Processor class. This manager also creates the menu component in the editor and I can communicate between the manager and the component easily. The major issue here is that if I have two instances of the same plugin and I save a new preset, let’s say, on instance B then I want that preset to show in instance A too.
One solution would be to force a rescan when the popup is shown, but I’ll be back on square one. Having the manager as a singleton sounds like suicidal. Any advice?
Thanks!
Luca
What is the problem with doing a rescan every time the popup is shown? This appears to be the best solution and as presets are files it’s only natural to do such a scan. Unless there is a kazillion of presets, a directory scan won’t take a long time.
A singleton is not an ideal solution for multiple reasons, the most important one imho is that it won’t work if the user has the plugin loaded in different hosts and/or loaded multiple formats (vst/au/etc.) at the same time.
Thinking outside the box here, but what about some kind of hidden file or registry/plist entry that holds a uuid. Hold a uuid in your preset engine, and each time the menu is called for, compare the two. If it’s different, rebuild. When an event occurs that changes something, write a new uuid to that place.
Probably some issues I’m not thinking about here, but it would greatly minimise the work, if it’s a problem.
Speaking of… is this a problem? Or is it more of an ocd tick where you know technically it could be better? (I get those too!)
1 Like
