A customer that built their own plugin scanning tool based on JUCE reached out to us since the scanner always reports 0 in/out channels for a recent VST3 plugin that we released while it reports a nonzero channel count for an older VST3 release.
Since that seemed odd, I tried to understand what was going on and stumbled over the fact that in case a plugin has a moduleinfo.json DescriptionLister::findDescriptionsFast decides to call DescriptionLister::tryLoadFast which will parse the json file and pass the parsed module info to createPluginDescriptions which will generate the plugin descriptions from it. That function sets the channel counts to hardcoded zeros:
This explains why the customers scanner code built upon the result of AudioPluginFormat::findAllTypesForFile contains 0 in/out channels for the new VST3 that contains a moduleinfo.json while the old VST3 did not contain the module info and therefore likely is scanned traditionally by instantiating the plugin.
I think this behaviour is slightly unexpected as it’s not documented anywhere. “Fixing” it would probably require actually instantiating the plugin which would make extracting the info from the module info to speed up scanning pointless? I general, I wonder if these simple channel counts actually make sense for more real-world scenarios. E.g. the plugin in question has a main and sidechain input bus, both with different numbers of channels possible, so I wonder how a single value can ever make sense here. But what about making these members a std::optional to be able to differentiate between really 0 channels or no information present?