Logic Pro keeps plugin running after closing session

Audio Plugins
1

Hi :slight_smile:

Logic Pro seems to keep the plugin running after the session has been closed.
If the plugin is a synth, it even keeps the audio loop!!

I’m on JUCE 7.0.12, Logic 10.8.1, on a Mac M2. Anybody experienced something similar?

To reproduce:

  • Create a new plugin from Projucer, default setting
  • Add the following code in the Constructor/Destructor of the plugin

//==============================================================================
NewProjectAudioProcessor::NewProjectAudioProcessor()
#ifndef JucePlugin_PreferredChannelConfigurations
     : AudioProcessor (BusesProperties()
                     #if ! JucePlugin_IsMidiEffect
                      #if ! JucePlugin_IsSynth
                       .withInput  ("Input",  juce::AudioChannelSet::stereo(), true)
                      #endif
                       .withOutput ("Output", juce::AudioChannelSet::stereo(), true)
                     #endif
                       )
#endif
{
    fileLogger = std::unique_ptr<juce::FileLogger>(
        juce::FileLogger::createDefaultAppLogger(
              "JUCE_TEST",
              "test.log",
              "-------- STARTING TEST LOG --------"
        )
    );
}

NewProjectAudioProcessor::~NewProjectAudioProcessor()
{
    fileLogger->logMessage("-------- CLOSING TEST LOG --------");
}

Then run the plugin and in a terminal, run tail -f ~/Library/Logs/JUCE_TEST/test.log to look at the test log.

You will see that the constructor is called when loading the plugin, and destructor called when removing the plugin.

But try loading the plugin and closing the DAW session (Cmd+Alt+W), and you’ll see that the desctructor is not called! Then load a new session and puf suddenly the destructor is called.

If you push it further and test the same with a synth plugin (for example the SamplerPluginDemo), you will see that the processBlock() is even still being called after closing the session… Weird?

Simon

2

This is a feature, not a bug, no? :slight_smile: Something-something AUv3 sandbox’ed processes, fast-load-time for next instance, etc. AUv3’s are not really plugins - but fancy processes with plugin-like IPC …

3

Yes fair enough, it is clearly by design and I guess Apple has a good reason for this…
And just FYI this is with a normal AU plugin, not AUv3.

4

Oh, I was just kidding anyway, but yeah, dunno if this is expected behaviour in AU … does the process eventually die?

5

Hosts are free to keep plugins alive as long as they desire. They can even re-use them if you close one instance and then open another. Often with DLLs on Windows, the memory is not reclaimed until the hosting app itself closes. This allows faster loading times for subsequent instances. Not sure how Apple/Logic handles this, but it’s perfectly reasonable behavior.

6

@ibisum : Yes the process dies when Logic is closed or when another session is loaded. What’s weird is if the new session has the same plugin, Logic will instanciate a new version of that same plugin, and only after it will terminate the previous instance of the plugin >_<

@HowardAntares : I was actually more surprised about the order of execution when opening a new session (as written above), as well as the fact that Logic kept calling the processBlock() :smiley:

7

There might be a rationale to that: if a plug-in has some shared resource between instances, it is probably reference counted and therefore gets deallocated when the count of instances goes to 0.

If Logic were to delete the lingering instance of your plug-in before instantiating the new one, the count of instances would go 1 → 0 → 1 in a short while, possibly causing the shared resources to be deallocated only to be recreated moments later.

Deleting the lingering instance of your plug-in only after the new one has been created, means that the instance counter does 1 → 2 → 1 and, because it never goes to 0, the shared resources are probably kept alive

1 Like