Checking if the AudioProcessorEditor is open from AudioProcessor

Audio Plugins
1

Is there a simple way to check if the AudioProcessorEditor is visible(open) from it’s corresponding AudioProcessor ?

2

The AudioProcessor normally doesn’t keep track of the editor(s) it creates. See AudioProcessor::createEditor(), it just create the editor and releases it into the wild.

However, nothing keeps you from adding some register/unregister functions to your AudioProcessor which are called from the editor’s ctor/dtor so you can keep a list of existing editors for a processor instance, which you can then query if they’re visible.

That said, if you feel the urge of doing something in the processor that only needs to be done when there’s an editor, it might be something that should really be happening in the editor instead. Before adding tighter coupling between the processor and editor, it’s always worth thinking twice.

4 Likes
3

You can always do something like (pseudo code):

struct MyProcessor: AudioProcessor
{
    std::atomic<bool> editorShown { false };
};

struct MyEditor: AudioProcessorEditor
{
    MyEditor(MyProcessor& processorToUse): AudioProcessorEditor(processorToUse), myProcessor(processorTouse)
    {
        myProcessor.editorShown.store(true);
    }

    ~MyEditor() override
    {
        myProcessor.editorShown.store(false);
    }

    MyProcessor& myProcessor;
};

I find that pattern to be useful for cases like meters, visualizers, etc where there’s also a cost to calculating things in the audio thread, and you’d like to remove that cost when the editor isn’t shown.

1 Like
4

Isn’t this prone to the edge case of, for example, the DAW creating a new editor for the plug-in before deleting the old one?

I’m thinking for example of when REAPER moves the editor from a standard window to a floating one and vice versa. I’m not saying that it behaves like that, I’m just saying that I wouldn’t be very comfortable with relying on the fact that the DAW does it in the order we expect it to.

Instead of a bool, I’d be much more confortable with an int that keeps track of how many editors are alive at the moment, increased in editor constructors and decreased in destructors

5

TBH I’m not sure JUCE in general supports more than one editor, but for correctness I agree that an int is better.

In fact in my real code I use an int, because often I actually connect the same meter source to multiple Components (not the big editor), and need to keep count of how many components that may poll the meter or visualizer are still on screen.

6

Not sure if it’s officially supported but I found it to work without problems: in fact, I use that to test the consistency of my MVC implementation.

In my debug builds I have a button to spawn a new editor pointing to the same processor as the original one, then I proceed to change one thing on one of the two editors, for example a slider value. If the change reflects identical on the other editor, then it means that the underlying data structure and notification mechanism all work correctly.

I always found it useful to think in terms of the possibility of multiple editors existing for the same processor, but I concur that probably no commercial DAW actually materializes that corner case.

1 Like