Reloading Synth

#1

Whenever I change any audio device settings (buffer size, output device, etc) in Logic, my synth plugin's destructor is called, followed by its constructor. This resets the synth, losing the last settings. Two questions:

1. Can this be avoided? 

2. If not, how do you handle it? 

The best thing i've got so far is whenever the destructor is called, saving the current setting in a temporary file. And whenever the constructor is called, checking for that temporary file, and if it exists, load those settings, and delete the temporary file. BUT, this only works if I have only one instance of the plugin open. If there are multiple instances then they all reload the same settings from this temporary file. Is there a way to identify the track number of each plugin to give them each a unique tmp file?

#2

OK so this goes deeper than I thought. I run into this problem any time the plugin is reloaded. So if I save the Logic session, re-open at a later time, it has no way of knowing what the synth's last settings were. I snooped around the documentation and found the PluginDescription class. But I'm a little confused on how to use it. Can I somehow get the current plugin's stats, store it in a plugin description, and then save that to file, any time the plugin is closed? But then how does the host know which saved file to open when reloading the session? Any examples would be EXTREMELY appreciated, as I am in the weeds.

#3

AudioProcessor::getStateInformation()

#4

So I use getStateInformation in my AudioProcessor's destructor and save that temporary preset to file. Then in my constructor I look for a temporary preset file, and if it exists, load it.

But I still don't understand how to differentiate between multiple temporary preset files. So if I have 3 instances of my plugin open in a session, they'll each save their own temporary preset. Then when I reopen the session later, each instance will see 3 temporary preset files, but not know which file is for which instance.

How can the plugin tell which file belongs to track 1's instance, which file belongs to track 2's instance, etc. Is there a unique identifier I can get from the host and store in the temporary preset file?

#5

The host should call your getStateInformation before it unloads the plugin instance. When the plugin reloads the host should call your setStateInformation. You have to implement the above methods to store/load the actual plugin state. There's no need for temporary files, unless you are using some weird host that doesn't support the state information methods.

#6

I see. That makes sense. I wasn't using setStateInformation properly, so the host was indeed calling it, but no changes were going through. Thanks!