Bug: JUCE 7.0.2 (Develop) AudioPluginHost doesn’t delete plugin

I’m running the develop branch downloaded October 14. MacOS.

What I just noticed is that right-clicking on my plugin and choosing “delete this filter” removes it from the staging area, but does NOT actually delete it. My AudioProcessor destructor is never called.

When I quit the APH, that is when my destructor gets called.

It works correctly in the 7.0.2 released version.

1 Like

I can reproduce this here as well. I’ll look into this and get back to you. Thank you for reporting!

1 Like

Still looking into this issue. For now, however, any change to the graph after having removed your plug-in from the graph, will actually call your destructor. So, for example, after having removed your plug-in, simply add one of the internal plug-ins to the graph.

I’m working on properly fixing this…

1 Like

This is now fixed with commit 11bd36b on the develop branch.

1 Like

@fr810 Why didn’t you use Timer::callAfterDelay() for this??

Rail

1 Like

Very good question. I might have been overly cautious, but it’s key here that the audio thread picks up the graph changes before the timer thread can delete the old state. If the audio thread takes a long time to run, and Timer::callAfterDelay() fires before, then the plug-in will never be deleted again.

Audio graphs are not limited to only real-time scenarios and we don’t want to restrict the way JUCE developers use them. It’s conceivable that in certain non-realtime scenarios (for example, offline rendering etc) the audio thread may block for a unknown amount of time.

1 Like

I’m curious as to: why did it break in the first place?

The AudioGraph was recently completely refactored to fix multiple issues including non-realtime safe behaviour. I think this is likely where it broke.

1 Like