Write the extra state of plugin in a chunk, so that the host can restore that later.
You would typically serialize arbitrary stuff with dplug.core.binrange.
This is called quite frequently.
What should go here:
* your own chunk format with hopefully your plugin major version.
* user-defined structures, like opened .wav, strings, wavetables, file paths...
You can finally make plugins with arbitrary data in presets!
* Typically stuff used to render sound identically.
* Do not put host-exposed plug-in Parameters, they are saved by other means.
* Do not put stuff that depends on I/O settings, such as:
- current sample rate
- current I/O count and layout
- maxFrames and buffering
What you put in an extra state chunk must be parameter-like,
just not those a DAW allows.
Contrarily, this is a disappointing solution for:
* Storing UI size, dark mode, and all kind of editor preferences.
Indeed, when loadState is called, the UI might not exist at all.
Note: Using state chunks comes with a BIG challenge of making your own synchronization
with the UI. You can expect any thread to call saveState and loadState.
A proper design would probably have you represent state in the editor and the
audio client separately, with a clean interchange.
Important: This is called at the instantiating of a plug-in to get the "default state",
so that makeDefaultPreset() can work. At this point, the preset bank isn't
yet constructed, so you cannot rely on it.
Warning: Just append new content to the Vec!ubyte, do not modify its existing content
if any exist.
Write the extra state of plugin in a chunk, so that the host can restore that later. You would typically serialize arbitrary stuff with dplug.core.binrange. This is called quite frequently.
What should go here: * your own chunk format with hopefully your plugin major version. * user-defined structures, like opened .wav, strings, wavetables, file paths... You can finally make plugins with arbitrary data in presets! * Typically stuff used to render sound identically. * Do not put host-exposed plug-in Parameters, they are saved by other means. * Do not put stuff that depends on I/O settings, such as: - current sample rate - current I/O count and layout - maxFrames and buffering What you put in an extra state chunk must be parameter-like, just not those a DAW allows.
Contrarily, this is a disappointing solution for: * Storing UI size, dark mode, and all kind of editor preferences. Indeed, when loadState is called, the UI might not exist at all.
Note: Using state chunks comes with a BIG challenge of making your own synchronization with the UI. You can expect any thread to call saveState and loadState. A proper design would probably have you represent state in the editor and the audio client separately, with a clean interchange.
Important: This is called at the instantiating of a plug-in to get the "default state", so that makeDefaultPreset() can work. At this point, the preset bank isn't yet constructed, so you cannot rely on it.
Warning: Just append new content to the Vec!ubyte, do not modify its existing content if any exist.