I bring this up here before starting a Github issue about it, because I think it should be discussed informally before taking that step. I also realize that v1.0 is feature complete & I wouldn’t expect it to show up in the 1.0 release.
I’ve looked at the Github issues and not seen this addressed. This could be totally dumb and unnecessary already, which if so, please tell me & I’ll drop it.
This goes back to the ‘normal’ experience with VST Hosts and VST Plugins, that there’s a factory preset list and a way to add user presets to the preset menu*
What would be great would be this:
Store ‘factory presets’ in a standard location per plugin – graphical assets already stored in the plugin folder, this seems a logical place.
Add to the context menu ‘presets’ that lets you choose from the list.
Add a context menu ‘save to presets’ to save a patch with the plugin assets, such that #2 will show user presets.
The idea being this: We can now load & save module presets but it involves bringing up a file dialog and navigating to where we want to save them. This would remove the step of file dialog/navigation, and list presets.
Secondary idea: Have a preset object that shows up in individual modules that lets you step through presets.
*VST Plugins are not consistent about how this is handled. The only consistent thing is that the host DAW saves the state of a plugin with the DAW project.
This feature already exists in Rack v1 for factory presets.
For user presets, <Rack user dir>/plugins/<plugin slug>/presets is not the correct place to store them, because everything in a plugin’s directory should be equal to the contents in the plugin ZIP package.
Where is the correct place for a plugin to store data that is outside of the scope of the patch json? For instance, my plugin generates MIDI files. Where should they go?
I can’t find the GitHub issue where I made this statement, but create a folder at asset::user(pluginSlug) with system::createDirectory(). In other words, <Rack user dir>/<plugin slug>/.
Finding createDirectory led me to getEntries which I missed in 0.6 (it was called systemListEntries there). Doh! I wrote a bunch of unnecessary code to work around that!
I’m especially thankful for getStackTrace in 1.0; my code is full of asserts to detect inconsistencies and it will make it much easier to trace problems back when the code fails outside of a debugger.