How to access the processorEditor from the process block

Audio Plugins
1

I just did the midi demo, so I’m new to this side of juce. I was thinking it would be nice to have a display of the results of the midi processing there in the plugin editor. Surprisingly, I found no 64-bit vst midi monitor vst anywhere online…

But it’s not clear how to send data to the editor from the process block method. I did a search here, and it seems that for very good reasons the processor should know nothing about the editor. So what is the approved way to approach something like this? Seemed easy, but maybe not.

2

You can add a method to your processor class…

YourProcessorEditor* YourAudioProcessor::getEditor() const noexcept
{
    return dynamic_cast<YourProcessorEditor*>(getActiveEditor());
}

Make sure to check the returned pointer isn’t nullptr before using it… also don’t hold onto the returned pointer and expect it to always be valid.

Rail

3

Also make sure you don’t do direct calls from the audio thread to anything that uses the GUI objects. (IIRC even a simple repaint() isn’t allowed.)

4

Rail - this looks pretty terrifying to me :slight_smile: There’s no guarantee it’s not being deleted while you use it … ?

5

They way I’d do this depends on how much information you want to send, but when we have lots of info in process block we want to get to the editor (e.g. a stream of audio to display on a graph) we use a FIFO. (See AbstractFIFO) and the processor puts stuff in the queue not worrying about whether the editor is there or not, the editor subscribes to the FIFO and pulls stuff from it.

You could set up a FIFO containing a copy of the midi data.

If it’s just a value, like a current meter reading, maybe a std::atomic that the editor reads on a timer.

There ought to be a whole book on this topic somewhere in a thread on this forum, but I can’t find it right now!!

6

As my comment says… don’t expect the returned pointer to always be valid… but it works if you check the returned value isn’t nullptr and use it to do something simple.

For my MIDI Logging I actually keep a pointer to the logging window and update the data from my processor’s processBlock():

    if (isEditorActive())
        {
        if (m_pMidiMonitor != nullptr)
            m_pMidiMonitor->copyMidiBuffer (midiMessages, iNumSamples);
        }

m_pMidiMonitor is set to nullptr if the Editor is destroyed and set to a valid value when the Editor is created. The logging is handled in it’s own thread.

Rail

7

I guess another way

You’d be okay if you were on the message thread I guess :slight_smile:

What happens in your example if the midi monitor is destroyed between the check for nullptr and the function call? :slight_smile:

8

What happens in your example if the midi monitor is destroyed between the check for nullptr and the function call?

Sounds like a risk I can live with for now…

But I am learning a lot from the discussion, and I will keep watching to see if there is a more robust solution…

Thanks!!!

9

I prefer to not push data from the processblock directly to the gui. I let the gui pull data that is updated in the processblock using for example fifo’s.

1 Like
10

With the two checks it never happens… I can open and close the Editor all day long without ever hitting an assertion.

Rail

11

I prefer to not push data from the processblock directly to the gui. I let the gui pull data that is updated in the processblock using for example fifo’s

That makes sense to me. I’m going to go read up on fifo’s…

Should I just create my own timer, or is there one associated with updating the gui already?

12

I bet it’s possible to crash it, just unlikely :slight_smile:

Unless I’m missing something here, if you are doing:

if (isEditorActive())
        {
        if (m_pMidiMonitor != nullptr)
            m_pMidiMonitor->copyMidiBuffer (midiMessages, iNumSamples);
        }

Ah - hang on…

is m_pMIdiMonitor owned by the AudioProcessor? That’d keep you safe…

13

Some in depth discussion on the matter here.

14

Should I just create my own timer, or is there one associated with updating the gui already?

Answering my question, looks like there are more tutorials than I knew about. Odd that they do not show up in the list of links at the bottom of the one I just did… The audio parameter tutorial deals with updating the gui from a timer, just in case this helps someone else, (and so no one feels obliged to point me to it.)

Thanks!