Plugin in Logic Pro only executes/updates some things when processing is enabled

General JUCE discussion
1

Hi there.
My plugin is running into a couple of issues in Logic unless playback is enabled (It also works well once the plugin is loaded and even if I enable playback for a second or two and then stop).

I am adding a processor to a chain dynamically and as long as processing is enabled, it works flawlessly.
Most of this happens in the processBlock (assigning the processing order, etc).

However, if I load a new instance of the plugin and never press the play button, trying to add the processor doesn’t do anything and if I then enable processing, still nothing happens.

There are a bunch of UI components (response curve of the EQ, for example) that also need playback to be enabled to be able to update.

Is there any way around this? I only encountered this in Logic. All other DAWs do this perfectly.

From what I read in a couple other posts, Logic seems to halt processing completely when playback is disabled.

Anyways, if anyone has any insight, please let me know!

2

No, I don’t think there is a workaround. processBlockBypassed won’t get called either. But regarding this:

There are a bunch of UI components (response curve of the EQ, for example)

You can also create filters as members of components. From my point of view, it is also a good separation of frontend & backend.

3

Hmm ok. Right now I’m thinking that the best way around it would be to have a flag that gets set to true in the processBlock and as long as it’s false, it’s impossible to try and add the extra processor.

However (I still haven’t tested this), but how long after playback stops until logic stops processing all together? Since I assume that I should somehow set that flag back to false at some point.

Or once the plugin is fully initialized, logic just keeps it online? Don’t know how to better phrase that, apologies.

I don’t fully understand this. Do you mean to have the filters as member classes of the, for example, ResponseCurve class, which would be in charge or actually displaying the response curve in the UI? Basically, frontend?

4

IIRC Logic would at least call processBlock if something pass through the plugin. But I cannot say it for sure. If you want to go this way, perhaps you can use a Timer to check it?

However, what if users deactivate the plugin? AFAIK most DAWs won’t call processBlock in this case. And users might expect your UI to be interactive (for example, the filter curve).

Yes. Basically at the dsp side you have some std::array<IIRFilters, 16> to process the audio samples and at the UI side you have some std::array<IdealFilters, 16> to calculate the response curve. You could also calculate the response curve at a background thread to reduce the load on the message thread.

5

Alright thanks!
Will do some digging and if I find anything meaningful I’ll post it here!

6

To add to this, with JUCE you don’t even need to make the actual filters on the UI side, you only need the Coefficients object, since the coefficients tell you all about the response curve.

Since calculating coefficients is pretty fast, it’s fine to do a bit of duplicate work in the UI. Plus, in the audio thread you’re probably smoothing the filter parameters or the coefficients, which you don’t need to do for the UI. So it’s best to keep the audio thread coefficients separate from the UI thread coefficients.

7

I would recommend creating another class to cache some complex values for magnitude response calculation. getMagnitudeForFrequencyArray will calculate those values per call, which is not optimal for performance.