My plugins use user settings to handle some persistent stuff like window size and certain controller mappings that are not expected to change when another preset is loaded.
Would it be a good idea to use a second AudioProcessorValueTreeState for the purpose? (while the first one holds those parameters that are included in presets)
I would love to use the serialization feature of the AudioProcessorValueTreeState to just dump my settings into a file.
Thanks for any input!
I’ve found the ValueTree to be great for this! Haven’t really thought of using the AudioProcessorValueTreeState, but I guess there could be benefits in that?
I have a class ConfigManager that holds the ValueTree and saves changed settings to xml file while managing the file io-lock. I’ve then have virtual ConfigOption, which is inherited for the actual settings:
class ConfigOption
{
public:
ConfigOption(ConfigManager &manager);
virtual ~ConfigOption() {};
/** Returns the default value for the config entry. */
virtual var getDefaultValue() = 0;
/** Returns tag to use with config manager. */
virtual const String getOptionTag() = 0;
/** Gets entry state from manager. If state value not initialized, initialize and return default value.
You may override this if additional functionality is needed for specific option. */
virtual var getOptionValueFromState();
/** Saves entry state to manager.
You may override this if additional functionality is needed for specific option. */
virtual void setOptionValueToState(var value);
protected:
ConfigManager& manager;
};
This way I can create “handles” to the user settings I need to access, and the ConfigManager takes care of thread locking etc.
I’d be very interested to hear, what sort of systems other people might be running.
If anybody is interested: I have now found a solution to my problem.
It is available from my github page.
PresetVsUserSettings
This example illustates some modifications I have made to the AudioProcessorValueTreeState class.
There are now two groups of Parameters that are handled differently:
- Preset Parameters - The state of these is saved with the preset.
- User Settings - Their state is loaded from a settings file when the processor is created. The file is saved whenever a user setting is changed and also when the processor is destroyed. It is recommended to disable host automation for this parameter group.
I purposely created the user settings as Parameters. This way both preset parameters and user settings are published to the host and can be modified through the host interface (if present).