VST3 hits assert in JUCE 6.0.8 that didn’t hit in 6.0.7: getNumPrograms()

Audio Plugins
1

I updated to JUCE 6.0.8, and now my plugin (under development) hits an assert that it didn’t used to hit before. But the assert is in the previous version.

It hits this assert at line 603 of juce_VST3_Wrapper.cpp:

    struct ProgramChangeParameter  : public Vst::Parameter
    {
        ProgramChangeParameter (AudioProcessor& p, Vst::ParamID vstParamID)
            : owner (p)
        {
            jassert (owner.getNumPrograms() > 1);     // hits this assert

I notice some code has been changed right around this area in 6.0.8, but the assert is the same as the previous version.

owner.getNumPrograms() calls into my AudioProcessor, for which I have this at the moment, since I have not developed this part yet:

    int getNumPrograms() override { return 1; }

I thought this was the default specified behavior if you don’t have any programs. Or should I report 0?

I’m not sure what has been changed, or what I need to do differently at this moment to avoid the assert.

1 Like
2

I should mention I am set to JUCE_FORCE_USE_LEGACY_PARAM_IDS=1.

I came across this discussion:

So I downloaded the dev branch.

I am now unable to create my plugin at all. I am now hitting an assert at:

    IPluginFactory* JUCE_CALLTYPE getPluginFactory()
    {
        if (factory == nullptr)
            if (auto* proc = (GetFactoryProc) getFunction (factoryFnName))
                factory = proc();

        // The plugin NEEDS to provide a factory to be able to be called a VST3!
        // Most likely you are trying to load a 32-bit VST3 from a 64-bit host
        // or vice versa.
        jassert (factory != nullptr);	// HITTING THIS ASSERT!
        return factory;
    }

…and continuing past this results in “Couldn’t create plugin. Unable to load VST-3 plugin file.”

Setting JUCE_FORCE_USE_LEGACY_PARAM_IDS=0 does not result in any change.

This is using the devbranch AudioPluginHost, Mac Mojave.

EDIT: this new assert seems to be a different problem, related to the fact that my built VST3 is now 8k in size, instead of many MB. See this:

3

The new develop commit on 03/26/21 fixed the VST = 8k in size issue.

However, my original problem above remains.

If I set JUCE_FORCE_USE_LEGACY_PARAM_IDS= 0, the assert goes away. If I set JUCE_FORCE_USE_LEGACY_PARAM_IDS=1, the assert returns.

4
5

Thanks, but It’s not fixed for me.

I still hit this assert (with JUCE_FORCE_USE_LEGACY_PARAM_IDS=1):

    struct ProgramChangeParameter  : public Vst::Parameter
    {
        ProgramChangeParameter (AudioProcessor& p, Vst::ParamID vstParamID)
            : owner (p)
        {
            jassert (owner.getNumPrograms() > 1);   // HITS THIS ASSERT

I only have this for getNumPrograms() at the moment:

    int getNumPrograms() override                          { return 1; }

I’m not doing anything for Bypass…

6

Thank you for reporting!

1 Like
7

Thanks, seems fixed! :smiley:

8

I had the same issue, and the changes in the Develop branch seem to have fixed it.

For my debug builds I had only been loading the plugin as an AU, so I hadn’t caught that same assert in the VST3 wrapper. Instead the first sign of trouble was when I went to try a release build, and my build script ran the pluginval tool to check the AU and VST3 formats.

Thankfully, pluginval threw this error, only on the VST3:

Starting test: pluginval / Plugin state restoration...
!!! Test 1 failed: Parameters not restored on setStateInformation -- 
    Expected value  within 0.1 of: nan, Actual value: nan

Further poking around revealed that my first parameter had been replaced by a “Program” parameter, and that it had an initial value of nan. Yikes!

9

We’ve now cherry-picked this fix (and another fix for the program parameter index with JUCE_FORCE_USE_LEGACY_PARAM_IDS enabled) onto the master branch.

10

Thank you, that’s quite helpful!

I can confirm that my build with the updated master branch now avoids that assert in the VST3 wrapper, and it also passes all the pluginval tests.

1 Like