Calling order of setStateInformation(...) and prepareToPlay(...)?

[parkellipsen]

I’m currently trying to restore a plugin state.

It seems like in Reaper the first call to prepareToPlay(…) is done before setStateInformation(…), so the necessary information to initialize my plugin isn’t present yet …

Is this the standard behaviour in all DAWs, or is the order different in others ?

Best,
n

[dave96]

This is valid behaviour. Your plugin should open with a default state (which could be uninitialised) and then the host will call setStateInformation at some point in the future.

Basically you have to be able to handle anything as a plugin…

[chkn]

@parkellipsen

Is this the standard behaviour in all DAWs, or is the order different in others ?

unfortunately there is no standard behaviour.

[pizzafilms]

Here’s another odd behavior from Cubase that you should be aware of as well:

Cubase calling setCurrentProgram after setStateInformation

I’m making sure that get/set stateInformation is working properly for my plugin in every host I can and it is in everything…except Cubase on the Mac. For whatever reason, it seems that Cubase is calling setCurrentProgram after setStateInformation when it loads a project with my plugin in it, and therefore destroying the state that the project was saved in. I tested other plugins and they seem work properly, but not mine…and only in Cubase. Does anyone have any clues here? Thanks.

[parkellipsen]

Hmm so basically, there’s no way to tell whether a plugin is just a added to a DAW session or restored as part of a DAW session at construction time. In the first case, the setStateInformation isn’t called at all in Reaper.

[daniel]

It kind of makes sense for the host to call setStateInformation at the beginning to make sure, the plugin is in the state as it would be when it is restored. But it is not a requirement, so the evidence works one way:

• If it is not called, it is definitely not restored (given the host implements save and restore )
• If it is called, it could be either way, like dave said, be prepared for both

[xenakios]

@parkellipsen

In the first case, the setStateInformation isn’t called at all in Reaper.

Which should not matter since your plugin should have some kind of a default state anyway. (Set up in the constructor and/or member initializers) Why would you need to set that up later in setStateInformation?

[dave96]

@parkellipsen

Hmm so basically, there’s no way to tell whether a plugin is just a added to a DAW session or restored as part of a DAW session at construction time.

Why would you need to know this? Does it determine some behaviour of your plugin? If so, you may need to rethink this as, yes, it’s not really knowable.

@parkellipsen

In the first case, the setStateInformation isn’t called at all in Reaper

What state would it set?

Remember there’s situations where you might be a new instance but have state, such as during a copy/paste operation.

TL;DR, you need to be able to deal with anything at any time…

[parkellipsen]

Well, it’s complicated … my current project requires to share information with the world outside the DAW, and restore a state based on an ID stored in the plugin’s memory block … so a default state would be rather useless in that context.

I’m thinking about a stateless solution, but so far i can’t think of any …

[parkellipsen]

Hmm the copy and paste thing is a good point … i have to think about that …