What about having the possibility to store only a bunch of controls of our choice, like a sub-preset for an FX section of an instrument, etc...?
I had this idea also a few years back, but backwards-compatibility is more important. If you add a control to your plugin, all user presets made with an older version will not change this control then (because it would be the same as your "subset"). For example if it's a convolution reverb with a big impulse response every preset will sound like it's placed in a cathedral which goes against the intuition of the preset builder.
The solution to this is to simply reset all controls to the default value if the control value is not found in a user preset (which is the case if you load an old user preset with an newer version). This way you just need to make sure that the default value is not modifying the sound if you add new stuff, and you're good to go.
I'm not sure if you can actually do this so it's just an idea.
It's a pretty bad idea actually. The
saveInPresetflag is not supposed to be changed after initialisation, there are tons of weird edge cases that makes this just asking for trouble.
Do not load user presets at startup.
I can't remember adding this safe check, but it's a good one. Why would you want to load a user preset at the beginning? Just make sure you've exported the plugin with the exact state of the user preset.
Why would you want to load a user preset at the beginning?
I don't I have a button that when clicked calls the
Engine.loadUserPreset()function and that is generating the message. The button has
Ah OK, then I'll take a look why it fires that false positive thingie. Better safe than sorry
Just looked, it checks the initialisation state which should be set to false after the initial state has been loaded. So I understand it right that this is happening when clicking a button with the mouse, yes?
I just realised you'd already suggested my
getFilesfunction a couple of weeks ago https://forum.hise.audio/topic/1146/viewport/24
lalalandsynth last edited by
Sub presets could be useful to save lfo shapes , just stumbled upon the need to do that so i thought I would mention it.
It's also not possible to add sub-folders in the file path.
Was this ever added? I'm playing with Content.storeAllControlsAsPreset() and I can only create a preset in the main User Presets directory. @d-healey Is there a way to set sub-folders?
@dustbro Not that I know of
What if you could just pass a
ScriptFileobject into these methods:
Engine.loadUserPreset( String relativePathWithoutFileEnding) Engine.saveUserPreset(String presetName);
Then you can create subfolders, add new files etc. as much as you want.
const var f = FileSystem.getFile(FileSystem.UserPresets).getChildFile("MyFunkySubFolder/AnotherSubFolder/3LevelSubfolder/Mindblowing4LevelSubfolder/Preset.preset"); Engine.saveUserPreset(f);
The old functionality will remain the same (so passing in a String will do whatever it does now).
@Christoph-Hart Looks good!
my only gripe with saveUserPreset() is that you have to load a preset first.
I had a method where I loaded an empty preset before saveUserPreset(), which was working great on everthing EXCEPT protools It didn't like the empty preset.
Is there some method I'm overlooking to load a preset without changing your current control settings? It just seems backwards to me
Content.storeAllControlsAsPreset() was great cause you could skip the whole "load a preset first" thing.
@dustbro all a preset does is store and restore control settings, so what would be the point of a preset that didn't change the controls when loaded?
@d-healey that's kind of my point. You can't use saveUserPreset() without first calling loadUserPreset() or else the newly saved preset will be created in an unexpected location.
From my testing, you have to load an existing preset within the sub folder location you want to save to. Then saveUserPreset() makes a duplicate (child? ) of that file and saves the new data to it.
So if you want to save your current settings as a preset, having to loading a preset first (which would change your controls) seems counterintuitive.
Maybe @Christoph-Hart could clarify
@dustbro ah I see the problem now, I think the changes proposed by Christoph will solve this already.