If you put it like that, yes. But that aspect is a design decision, so you can argue which way you prefer.
What you cannot argue, is that you set something in the editor from processBlock. The processBlock happens on the AudioThread, that is running unsynchronised from the messageThread. So you cannot know, if the editor is being destroyed, while you are executing the statement inside your
if (editor) block.
You can access the editor from the processor under certain restrictions:
- you make sure the MessageThread is not interfering, a) making your editor.currentRMS atomic and b) hold a MessageManagerLock (which is a no-go inside processBlock() )
- you are calling from the MessageThread yourself, e.g. as result from a Timer (which shows, why it makes more sense to have that Timer in the Editor) or using MessageManager::callAsync (also a bad idea inside the processBlock)
It is a good thing to spend time thinking, which operations in the AudioProcessor are executed from which thread, as this is the place, where the two time dimensions meet (audio thread and message thread).
I hope this makes the problem understandable.