Plugin for Nuendo Surround Panner with juce6

[Chikashi]

Recently we update our plugin to Cmake + Juce6 and realized that it doesn’t show up as a plugin for Nuendo Surround Panner (see the image) though it was shown before in the list.

I gave AudioProcessor so many different options for the IO combination
AudioPluginAudioProcessor::AudioPluginAudioProcessor() : AudioProcessor({ {16, 16}, {1, 2}, {2, 2}, {1,3}, {2, 3}, {1, 4}, {2, 4}, {1, 5}, {2, 5}, {1, 6}, {2, 6}, {1, 7}, {2, 7}, {1, 8}, {2, 8}, {1, 9}, {2, 9}, {1, 10}, {2, 10}, {1, 11}, {2, 11}, {1, 12}, {2, 12}, {1, 14}, {2, 14}, {1, 16}, {2, 16}, {3, 3}, {4, 4}, {5, 5}, {6, 6}, {7, 7}, {8, 8}, {9, 9}, {10, 10}, {11, 11}, {12, 12}, {14, 14} })

and AudioPluginAudioProcessor::isBusesLayoutSupported() returns always true

bool AudioPluginAudioProcessor::isBusesLayoutSupported (const BusesLayout& layouts) const
{
    return true;
}

In CmakeLists.txt I also set

VST3_CATEGORIES Spatial

Would there be a way to make Nuendo recognize my plugin as a surround panner plugin?

Nuendo Version 10.2.0
Juce Version 6.0.4

[mcmartin]

What exactly did you have in the .jucer project as pluginVST3Category?

[reuk]

Does the plugin show up in other hosts? For example, can the JUCE AudioPluginHost discover and load the plugin?

It might also be worth testing with VST3_CATEGORIES Spatial Fx - according to the VST3 headers these categories are “used for SurroundPanner and as insert effect”

[dearRealityDev]

Having the same problem here.

Currently, moved away from the initializer list and implemented with our own isBusesLayoutSupported and an initial BusesProperties for the parent AudioProcessor.

VST3_CATEGORIES is set to Spatial Fx Ambisonics Up-Downmix

The weird thing is: loading an old version of our plugin and looking at it in the VST Plug-In Manager in Nuendo shows IO as:

Mono/Stereo

and now (no matter how I tweak the isBusesLayoutSupported or the initial configurations) the IO shows up at

3rd Order Ambisonics / 3rd Order Ambisonics

This is the only guess I have for why it is not showing up in the panning slot…

(additional note: because of the update to JUCE6, the new plugin is a VST v3.6.13 and the old is v3.6.9)

[dearRealityDev]

Okay, so it looks like the problem is:

the JUCE6 cmake tooling will forcibly place “Fx” as the first category in the VST3_Categories list. Nuendo is apparently not okay with this.

Removing lines 1464,1467 in JUCEUtils.cmake fixes the problem:

if(Fx IN_LIST vst3_categories)
  list(REMOVE_ITEM vst3_categories Fx)
  list(INSERT vst3_categories 0 Fx)
endif()

Is there a specific reason that Fx is being set as the first item in the list? If not, I would gladly put in a PR to fix this.

[mcmartin]

@dearRealityDev

Is there a specific reason that Fx is being set as the first item in the list?

Projucer does exactly the same thing:

juce-framework/JUCE/blob/6.0.5/extras/Projucer/Source/Project/jucer_Project.cpp#L2107-L2108

This is why I asked:

@McMartin

What exactly did you have in the .jucer project as pluginVST3Category ?

[dearRealityDev]

It looks like whoever wrote this code had hardcoded it as a define in the project previously in order to bypass this feature of Projucer.

[ed95]

Projucer: VST3 Category Order and Missing Category

Thanks, I’ve added the “Dynamics” category. I’ve also changed the getVST3CategoryStringFromSelection() method so that the priority of categories is “Fx” > “Instrument” > everything else but I can’t find any official documentation on the order that categories should be in. Confusingly, ivstaudioprocessor.h defines a few categories that can be used and kSpatialFx is defined as “Spatial|Fx” which implies that “Fx” shouldn’t always be first?! If there is some canonical way of ordering the categorie…

It’s pretty ambiguous and there’s nothing in the VST3 spec about it, but Fx is first for host compatibility reasons. It seems like Spatial needs special-casing, but again there’s no actual documentation on what the order should be so it’s hard to know whether this will break other hosts…

[mcmartin]

@dearRealityDev

whoever wrote this code had hardcoded it as a define in the project

If I understand you correctly, there is something like

defines="JucePlugin_Vst3Category=Spatial|Fx|Ambisonic|Up-Downmix"

in your .jucer project file, but it was not migrated to the CMakeLists.txt. That would definitely explain why your plugin doesn’t get recognized when built with CMake. It would also mean that your only fix (for now) is to add that define to your target in your CMakeLists.txt.

[daniel]

Maybe someone could get in touch with Steinberg and ask for clarification, since they own VST3 and Nuendo, they should know, or at least can make it work (if anybody).

[PeterRoos]

I see that Ed has committed this on 2018-08-06, with message

Projucer: Ensure that either “Fx” or “Instrument” is added to the VST3 categories when saving a plugin project

[dearRealityDev]

yes, breaking compatibility is definitely a problem. However, it would be ideal to not have to work around this issue. Maybe an option to prevent the re-ordering would be a good idea?

If I understand your linked forum post, this re-ordering of Fx was only changed in 2018? When this was implemented, did you have any issues with breaking host compatibility?

Another potential solution might be to place Spatial at the front of the list automatically. However, I suspect this is also not ideal.

[ed95]

Maybe an option to prevent the re-ordering would be a good idea?

This might work for a CMake-based project, but for the Projucer it would then be dependent on the order of the categories in the GUI which isn’t ideal.

Confusingly the VST3 SDK defines both Fx|Spatial and Spatial|Fx as being separate, valid categories so placing Spatial first isn’t the right thing to do either. I think the current solution is the least-worst, and if you need more control over the category string like your case then you can define JucePlugin_Vst3Category yourself to override the setting.