Doing FFT processing on Editor thread?

Audio Plugins
1

I am working on a simple tuner VST plugin. You play a tone, I do some FFT/other math, and I change a label in the plugin to show the note and octave. Simple.

My plugin has two simple elements, from the ProJUCEr setup:

  1. class MyAudioProcessor : public AudioProcessor
  2. class MyAudioProcessorEditor : public AudioProcessorEditor, public Timer

My plan is to read off new buffer samples in MyAudioProcessor::processBlock(), put them in a sampleBuffer (readable by MyAudioProcessorEditor), and then, every 50ms (?) or so, have the MyAudioProcessorEditor::timerCallback() pull off samples, perform the FFT, and update the GUI.

(With only one exception, all the integer read/write heads will be writeable by only the AudioProcessor OR the AudioProcessorEditor. That last one I’ll have to setup as atomic or something?)

Is this a reasonable architecture? I chose this way since I was told you want to do as little in the processBlock() audio thread as possible.

However I’ve never used JUCE or C++ before so I’m looking for some advice on setting up good plugin design, and I wasn’t sure if the editor thread would be prioritized by the OS, etc! Thanks.

2

NOT a good idea. The editor might even not be there! Do all audio processing on the audio thread!

2 Likes
3

You are correct to do as little in the processBlock as possible. And pushing the samples into a FIFO structure makes much sense.
However, it is also good practice to keep the message thread free as well, since that is shared with all other GUI tasks of your DAW. If you put too much strain on it, sometimes you can even see the DAWs UI becoming sluggish, so ideally you would put the computation on an extra thread too.
I have a public example implementation, where you can get inspiration: