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

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 ?


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…

unfortunately there is no standard behaviour.

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

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.

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 :wink: )
  • If it is called, it could be either way, like dave said, be prepared for both

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?

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.

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…

1 Like

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 …

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