• This function seems to act a bit strangely when overwriting an existing file, it doesn't always save the values of the controls. Also if we add a .preset extension to files saved with this function will they be displayed in the preset browser and will they be picked up by thegetUserPresetList function?

  • This bug seems to still be present. It's also not possible to add sub-folders in the file path.

    In order to be able to build custom preset browsers we really need working functions to save and load presets, and retrieve preset names with full preset folder structure.

  • Ok, here's what we do - because clearly I don't care about this function because I'll never use it 🙂

    • you'll write the API documentation for this method with the exact parameter inputs and how it works and which files are being created.
    • I'll implement it exactly as you want

    Just drop the lines here, I'll add it to the API docs later.

  • I've come up with 3 related functions that I think would support a broad range of custom preset browser implementations. Let me know if you have better suggestions 🙂

    Content.storeAllControlsAsPreset( String filePath)
    Saves the values of all controls that should be saved into a file. If the file already exists the user will be prompted to choose to continue and overwrite or cancel.

    I think if the file path starts with {PROJECT_FOLDER} it should use the UserPresets folder as root. Any directories specified in the filePath that don't exist should be created. The file extension should be specified as part of the filePath - This way we can use the system for storing files other than .preset if desired.

    Content.restoreAllControlsFromPreset( String filePath)
    Restores all control values store in the given file.

    This is pretty much the same as the Engine.loadUserPreset() function but allows a little more flexibility with the filePath. I think it should default to UserPresets as root when {PROJECT_FOLDER} is the start of the path.

    Engine.getFiles( String filePath)
    Returns an object that contains folder and file names (including sub-folders/files) contained in the given filePath.

    I assume that operating systems will limit which folders HISE can access, if so I think it is reasonable to limit the root of the search to the project folder.

  • @d-healey Just an idea (might not be a good one though)
    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...?
    It's not vital but could be a nice add-on

  • @ustk I think you can just turn off the saveInPreset setting for controls you don't want to store before you save the preset

  • @d-healey In fact, that wasn't the idea, because you still might want to store these controls in the global preset... But again, maybe not enough people will find this useful so... 😇

  • @ustk No I meant disable the saveInPreset button only when saving a sub-preset, the rest of the time you have saveInPreset enabled. I'm not sure if you can actually do this so it's just an idea.

  • Somewhat related to this discussion.

    The Engine.loadUserPreset(""); function is causing this console message - Do not load user presets at startup.. This also happens in the custom preset browser example project.

  • 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 saveInPreset flag 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.

  • @Christoph-Hart

    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 saveInPreset disabled.

  • 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?

  • @Christoph-Hart Correct

  • I just realised you'd already suggested my getFiles function a couple of weeks ago 😛

  • Sub presets could be useful to save lfo shapes , just stumbled upon the need to do that so i thought I would mention it.

Log in to reply