Load state vs. default state flow

Hello,

I’ve a plugin that loads samples. I have some parameters and depending on that it loads different samples. I store those parameter like described in this tutorial.

My problem: The function that loads the saved state can trigger early or late, I think it depends on the DAW. So this is a problem of “load defaults” vs. “load saved state” when the plugin starts.

My current implementation is like this:

The function that loads the samples is called PluginProcessor::loadSamples(...)

In the function that triggers when a state is loaded (setStateInformation) I call the loadSamples function. So in case the DAW has a stored state if goes that flow and it loads everything successfully.

But when you add the plugin to a new project in a DAW, there should be an initial/default state so it loads the samples. In this case, the setStateInformation will not trigger because there’s nothing stored. SO for this case I have the following code in my PluginProcessor::prepareToPlay function:

auto asyncFn = [&]() { 
    juce::Thread::sleep(200);   
    if (!samplesAlreadyLoaded) {
        loadSamples(...);
    }
};
std::thread(asyncFn).detach();

This seems to work, but isn’t that hacky as hell? I mean, this is just something like a fallback in case nothing has been loaded and if so, then it will load the samples with the default parameters.

I have to know the parameters before I load the samples, because depending on the parameters it will be different sample files…

What is the best practice to handle this case? I’d like to get rid of that dirty code. Because my code is not efficient if the default-flow (waits 200ms) and it also can fail if the load-state-flow is slower than 200ms … I guess you know what I mean.

Any hints are welcome :slight_smile:
Have a nice weekend

I’ve encountered the same problem and have ended up with the same solution - from what I can tell there’s no way to know if a DAW is going to load a plugin state until it does :person_shrugging:

Why not always load the default samples, immediately after creating your parameters and setting their default values, and then if setStateInformation() happens to be called later, load the samples based on that state information? That seems more logical to me.

2 Likes

Could you give some examples of DAWs that work and DAWs that don‘t work? I was recently working with the Kontakt AU and Kontakt refused to load anything in setState when it is not actually playing.

the usual way to do this is to let the parameters have a default value themselves. some hosts, like JUCE’ standalone build, will call setStateInformation regardless, but then you can just say if the valueTree has no state for that parameter yet do nothing. some DAWs, like cubase, will only call setStateInformation if there has been state before. Also make sure to never save something to or load from your valueTree in the constructor of the audioProcessor cause it will be overriden shortly later in setStateInformation anyway