AUv3 - AudioUnitPluginFormat::findAllTypesForFile

Hi JUCE devs!

A weird one for you.

The following code…

void AudioUnitPluginFormat::findAllTypesForFile ...
...
    if (MessageManager::getInstance()->isThisTheMessageThread()
          && requiresUnblockedMessageThreadDuringCreation (desc))
        return;

… prevents AUv3 units being picked-up by a plug-in scanner, if the app is making the call to JUCE from the MessageManager thread, e.g.:

    juce::MessageManager::callAsync([this] {
        // Make the call here
    });

If I scan instead from a different thread, it works.

However, I made the change to scan from the MessageThread to deal with a crash I saw on iOS when processing Apple’s built-in plug-ins.

Any suggestions?

Pete

Most AUv3s require the main thread to be unblocked during creation, so I don’t think there’s much we can do about the message manager check.

The AudioPluginHost project calls findAllTypesForFile from a background thread and doesn’t crash when loading the built-in Apple AUs (at least, in the simulator), so I’d recommend taking another look at the crash you were seeing. It’s probably possible to debug your app so that it can also scan plugins from a background thread without crashing.

Thanks @reuk

I’d suggest you might want to use jassertfalse rather than just returning?

Anyhow - GraphEditorPanel.cpp uses this very specifically for iOS:

class AUScanner

Is there a specific undocumented reason for this?!

Best wishes,

Pete

On desktop platforms, the plugin scanning would be handled by the known plugin list window. However, on iOS we use a simple slide-out menu instead, and this menu doesn’t include a button to rescan plugins (unlike the desktop window). It looks like the AUScanner is just used to automatically scan all plugins without needing to use a PluginListComponent.

1 Like

OK, thanks @reuk !

Pete

So what does that mean in practise, for the thread to be unblocked? How should the application ensure that’s the case when creating instances of such plugins?