From processor to editor


#1

Hi. I was just wondering what the best method would be to send data from the ProcessBlock function in the plugin processor, to the plugin editor? I have made a level meter that collects a value from the processor, but would like to change it so that the processing is done within the level meter class rather than in processblock. In essence, I am just looking to just send a variable to the editor.

Many Thanks


#2

I think that if you set your processor as a ChangeBroadcaster, and set your editor as a ChangeListener of your processor, you can update the last one calling sendChangeMessage() from the first one.
Cheers


#3

Many thanks. I am more trying to call a function in the editor, for instance I have a function in the editor which should receive the buffer value at the end of the ProcessBlock method:

in this function, the buffer value is manipulated and sent to the relevant level meter where all the code is manipulated further.

I can’t seem to figure out how the editor is attached to the processor. I have found this function:

AudioProcessorEditor* TheFunctionAudioProcessor::createEditor() { return new TheFunctionAudioProcessorEditor (this); }
but it does not give me an identifier to attach to, eg I want to call

(but obviously with the correct identifier)

Many Thanks, and apologies if I am being silly and overlooked something simple. :oops:


#4

Your processor should not know about the editor, and shouldn’t call any functions in it. You also need to assume that there could be zero, one, or many editors attached to the processor, and that this could change at any time, so the links should always be in the other direction. The best approach is either to make an editor periodically check its processor to see if anything has changed, or to have a listener/broadcaster system that allows the editors to register themselves with the processor for callbacks about something - but be very very careful about thread-safety if you do that.


#5

Many thanks for a quick reply Jules, it makes perfect sense now!


#6

I would add that be careful with sending or calling buffer after having done the processing job.
I tried same thing and the time that took editor to exploit buffer was higher than time between two calls of processBlock function, and so editor could not update itself fast enough and get a lag which blocks repainting stuff.


#7

Ok thanks nicolas. Basically what I’ve done is create an empty AudioSampleBuffer (foo) in the processor. At the end of every processBlock method, I add the processed buffer to the end of the foo buffer (as there may be more blocks of audio than the meter refreshes). When the timer in the editor decides it’s time to redraw, I find the magnitude and RMS (for 2 different meters) values of the foo buffer, update the meters, and reset the foo buffer (and variables). Is this the right way to go? it seems a little choppy and I’m not sure if clearing the foo buffer from the editor is the best practice.

Many Thanks


#8

It’d be vastly more efficient to use a circular buffer, e.g. based on the AbstractFifo class.


#9

Thanks. I’ll have a delve into that. There’s so much cool stuff in Juce and many ways round things. I’m well impressed! (I’m a relative Juce noob :))