AudioPluginHost and Roland Cloud VST3 plugins on MacOS

MacOSX and iOS
1

I’m trying to scan VST3 plugins from Roland Cloud on MacOS with AudioPluginHost built with JUCE 5.4.5 (have tried 2 different PCs, one running Mojave and the other one with Catalina). Same behaviour for all Roland plugins - scaning stuck (no CPU consumption), I can wait hours and nothing happens… When I try with any other Roland Cloud plugin it’s exactly the same…

Notes:

  • Roland Cloud plugins in AudioUnit format work fine (both VST3 and AU come form the same latest Roland Cloud release I guess)
  • other vendors VST3 plugins are being scanned without issues
  • other VST3 hosts (like Studio One) scan and open Roland Cloud VST3 plugins without issues

So seems like it’s only with JUCE <–> Roland Cloud VST3.

Useless screenshot:

obraz

2

Thanks for the report. I’ve got in contact with the Roland Cloud developers about this and am waiting to hear back.

From looking into this, I think the issue is that the plug-ins are doing some UI work in the bundleEntry()/InitModule() methods and Xcode’s main thread checker is throwing an exception because the AudioPluginHost will scan plug-ins on a background thread. If I make the scanning happen on the main thread, the plug-ins are scanned correctly and no exception is thrown. However it does take ~5 seconds or so to scan them which makes me think that some server authentication or something is also happening in the entry points. I’ll update this thread if/when I hear back from the developers.

1 Like
3

I did some small research on that. Because of the Roland Cloud auth, I had to add NSAllowsArbitraryLoads set to True in the plist. That helped with some exception, but did not fix scanning. When debugging I noticed scanning stuck at ComSmartPtr::loadFrom - component.loadFrom (factory, info.cid) called from the DescriptionFactory::findDescriptionsAndPerform. It’s body has this:

    bool loadFrom (Steinberg::IPluginFactory* factory, const Steinberg::TUID& uuid)
    {
        jassert (factory != nullptr);
        *this = nullptr;
        return factory->createInstance (uuid, ObjectType::iid, (void**) &source) == Steinberg::kResultOk;
    }

and it was the createInstance not returning (waiting and blocking). I have noticed the VST3 loading and instantiating purpose is to determine In/Out channels only so that createPluginDescription can be called (apart from testing if it loads at of course:) ), so I did a temp workaround - instead of calling component.loadFrom (factory, info.cid) I am simply creating effect’s description with 2 Ins and 2 Outs:

createPluginDescription (desc, file, companyName, name,
                                     info, info2.get(), infoW.get(), 2, 2);

Roland Cloud VST3 plugins load and work perfectly fine into the AudioPluginHost (so it was only the scanning thing). Interestingly, their channels/buses configuration is correct in the graph (as if the createPluginDescription with 2 Ins/2 Outs was ignored).

@ed95 Thank you for helping on that! I will try calling that ComSmartPtr::loadFrom (Steinberg::IPluginFactory* factory, const Steinberg::TUID& uuid) on the main message thread just to see it’s working:)

4

Any updates on this one? Having the same problem. Not sure if it affects all JUCE plugin loading code or just AudioPluginHost…