Solved Preset System Questions…

[clevername27]

Can someone please help me with these preset questions? I have…so many questions.

1. If a default preset is used, does saving/loading to/from the DAW work as expected (as per this thread)?

2. Is it correct that every component's (that's saved in a preset) control callback is called automatically when a preset loads — and that this process is asynchronous?

3. If so, exactly what is completed before setPostCallback is called?

• If it's literally just the component values being loaded, doesn't that happen instantly?
• If it's after all the control callbacks for the components fire, then how does setPostCallback know when they've all completed?

4. If the restoring process is asynchronous (all/any happening at the same time), how do I handle changes to my plugin state that are the result of a specific chain of component data value changes (ny the user)?

5. If a preset includes a sample map, is it correct that restoring this sample map is a separate process than restoring a preset? As in, there needs to be a component that chooses sample maps, and when the preset is loaded, my control callback is called that loads the sample map. The setPostCallback wouldn't be relevant here—I need to use the onLoad callback specifically for sample maps?

6. Is it possible to hide the default preset from the user (so it doesn't show up in the preset browser)?

7. If components have default values, the plugin is saved when compiled (and restored when instantiated), and there is a default preset—what takes precedence?

8. Are panel data slots written to preset files?

9. What is the best way to save/restore component visibility and enabled state?

10. If addModuleStateToUserPreset module states—

• Does the setPostCallback wait until all those values are loaded, as well?
• How are those values restored? (Is it with updateConnectedComponentsFromModuleState?)

9. Is there an API to restore the default values of all components?

10. Why are these methods necessary—doesn't the preset system do these things automatically?

• Content.restoreAllControlsFromPreset
• storeAllControlsAsPreset
• restoreAllControlsFromPreset

11. Why do so many people seem to have trouble reading/writing/finding preset files?—are there best practices here?

I doubt anyone is still reading at this point. But if so, thank you!

[d.healey]

2. Yes - I think it's synchronous, in the order the components are listed in the widget list (top to bottom).

3. The components values are loaded, and their callbacks are triggers - so whatever action you have assigned to the controls will happen before the post callback.

4. Presets don't include sample maps - they only store the state of the controls (and CC automation assignments).

5. Not with the stock preset browser

6. The default value (as set in the interface designer) is the value the knob will jump to when double clicked. - I'm not sure what purpose it has for buttons.

7. No, only the panel's value.

8. How are you setting the visibility/enabled state?

9 again) You'd have to do that in the post callback manually - but why use the saveInPreset in that case?

10 again) restoreAllControls can be used after a preset has been loaded to go back to those settings - maybe for an A/B system, I'm not really sure. The other two functions are useful if you are using a custom preset system.

11. Who?

[clevername27]

@d-healey Thank you for taking the time for all those replies. If I may ask a few follow ups?

• Do we know if default presets can be used, and also save/load with DAWs? (In the post I linked, you mentioned it wasn't possible.)

• I think the numbers got jumbled a bit between my questions and answers - could you please take a look? (I know I asked a lot of questions.)

• I'm setting the visible and enabled states with scripting, and there's like 50 of them. (They then are changed dynamically while the plugin runs.) Would be amazing if that initial state could be stored in Presets.)

[Christoph Hart]

1. If a default preset is used, does saving/loading to/from the DAW work as expected

Yes, the default preset only makes sure that the state that the plugin is loaded is consistent and not depending on the state it was when you export it - it's rather a development tool than a real feature.

2. Is it correct that every component's (that's saved in a preset) control callback is called automatically when a preset loads — and that this process is asynchronous?

The control callback of each saveInPreset component is executed in the sample loading thread synchronously (while the scripting thread is stalled).

3. If so, exactly what is completed before setPostCallback is called?

The post callback will be executed asynchronously on the scripting thread after the preset has been loaded and each control callback has been executed (and the module states have been restored and the MIDI learn config has been changed).

4. If the restoring process is asynchronous (all/any happening at the same time), how do I handle changes to my plugin state that are the result of a specific chain of component data value changes (ny the user)?

It's not asynchronous in the sense that it's guaranteed that the order of execution of the control callbacks is always the order of definition, so if a control is dependent on another component's value, it needs to be put after the other in the component list.

5. is it correct that restoring this sample map is a separate process than restoring a preset?

If you load the samplemap caused by a control callback that is executed in the sample loading callback, it will load the samplemap synchronously in the sample loading thread where the user preset is being restored, but the preloading of the samples will be executed later so that the user preset loading is not delayed.

6. Is it possible to hide the default preset from the user (so it doesn't show up in the preset browser)?

Yes. The default preset does not have to be in the user presets folder (so if you put it in the project root and use ../Default.preset as default path, it will not embed this as actual user preset (that's how I'm doing it in a project so I know it works :)

7. If components have default values, the plugin is saved when compiled (and restored when instantiated), and there is a default preset—what takes precedence?

The default user preset takes precedence - that's the entire reason of existence of this concept, so that you don't have to make sure that you accidently export it in the wrong state. It will also revert the values before saving the actual XML preset file so your git commit history will not be polluted with bogus value changes.

Be aware that Protools for some reason always ignores the state of the controls and sets each (automatable) plugin parameter to its default state as indicated by the defaultValue parameter (btw. this is why this is important for buttons too).

9. Is there an API to restore the default values of all components?

https://docs.hise.audio/scripting/scripting-api/userpresethandler/index.html#resettodefaultuserpreset

10. The post callback will be executed after the module state restore.

However if the restoring of the module state triggers another asynchronous action, it might mix up the order but that's a very niche edge case. The module state will be restored the same way as if you load your project in HISE - it will take the base 64 encoded XML state and restore all values (Look for restoreFromValueTree() in the hi_core/hi_modules directory for how it works.

Why are these methods necessary

They aren't. Most of them are super ancient and only kept around for backwards compatibility.

[clevername27]

@Christoph-Hart Thank you - and this is fantastic, will save so much time -

The post callback will be executed asynchronously on the scripting thread after the preset has been loaded and each control callback has been executed (and the module states have been restored and the MIDI learn config has been changed).