This must be as old as the hills… or I’m an idiot and missing something fundamental.
AudioprocessorEditor has a member variable which is an AudioProcessor&
Both its constructors set this reference, and any subsequent calls to getProcessor() just return it.
But it’s quite possible that the AudioProcessor is destroyed before the Editor. And the processor doesn’t actually own the editor either. In fact I have this situation in Pro Tools right now. (repro instructions on request). So there’s no really standard no way for Editor to know if Processor has disappeared. So we get a crash.
How have people been managing this all these years???
Best idea so far is to notify the Editor object when Processor is closing, then set a member variable (pointer) to nullptr… and only ever use this pointer to access the processor object
It’s safe to assume that an editor will be deleted before its processor. (cf doc of AudioProcessor::createEditor())
Can you share the steps to reproduce?
In Pro Tools:
insert the plugin
insert a second one and open its UI
drag the first onto the slot with the second (without accidentally opening the first UI)
~AudioProcessor is called
~AudioProcessorEditor is called.
So if you’ve got anything at all in the UI relying on processor, you’ve got a crash.
That is not what is normally happening.
The API promises that an editor is destroyed before the processor it is connected to.
Can you check, that it is not the processor dtor of the instance where no editor was open? If you verify with DBG statemenrs, print the addresses with it.
OK I’m wrong.
Here’s what happens when dragging instance 1 to replace instance 2 (with its gui open):
Destroy Processor for instance1
Destroy Editor for instance 2
Create Editor for Instance 2 (referencing same address as the previous Processor)
So I guess Pro Tools doesn’t actually kill the “replaced” plugin at all. It must just close the UI, then apply the state of the incoming instance to the existing AudioProcessor object.
