What could be the cause of one specific VST3 plugin (Pivot Lite, on Windows PC) getting different identifier string out from Async loading, than what was given into it? Other plugins work just fine, but just that single plugin causes weird behavior in JUCE.
Here’s the code in a nutshell:
// Async load callback function
auto callback = [this] (std::unique_ptr<AudioPluginInstance> p_plugin, juce::String error_message)
{
auto DEBUG_plugin_id_2 = p_plugin->getPluginDescription().createIdentifierString();
// ERROR: The above DEBUG_plugin_id_2 is NOT the same as the original plugin_id or DEBUG_plugin_id_1 !!!
};
// Get plugin description from KnownPluginList based on plugin ID
auto p_plugin_description = mp_known_plugin_list_fx->getTypeForIdentifierString(plugin_id);
// Test that the plugin description has the same plugin ID we asked for
auto DEBUG_plugin_id_1 = p_plugin_description->createIdentifierString();
jassert(DEBUG_plugin_id_1 == plugin_id);
// Async load the above VST3 plugin
void AudioPluginFormatManager::createPluginInstanceAsync(*p_plugin_description, ..., callback);
The plugin ID given to createPluginInstanceAsync() is “VST3-Pivot-Lite-5a2b6905-18755a03”.
The one that comes out of the p_plugin inside the callback function is “VST3-Pivot-Lite-deadacd6-18755a03”.
AudioPluginHost seems to load the plugin just fine, as well as save the project file and reload it again.
Additional observation:
PluginDescription::createIdentifierString() calls getPluginDescSuffix(….), which uses PluginDescription::fileOrIdentifier to create a hash code for the ID. That fileOrIdentifier in this exact case is:
@Kraku thanks for reporting. I’ve been taking a look at this and there are a number of moving parts to consider, so it would be good to explore what the main challenges for you are.
Having had a closer look it seems any plugin that contains a moduleinfo.json file will use a faster mechanism for loading the plugin details. On Windows when this happens PluginDescription::fileOrIdentifier will be set to the path of the .vst3 plugin bundle. Whereas any plugin that uses the slow mechanism, or any plugin that has actually been instantiated will set PluginDescription::fileOrIdentifier to be the path of the specific .vst3 dll located inside the bundle.
This isn’t ideal but I’m just giving some context of what is actually happening.
Unfortunately yes at the moment that does appear to be the case.
That being said I think we could update PluginDescription::matchIdentiferString() to ignore the path with little to no disruption. This actually better matches the docs which suggest the identifier string is independent of the plugin location (which is obviously not true).
Unfortunately updating the value of PluginDescription::fileOrIdentifier is slightly tricky as there is a risk that by changing the output of PluginDescription::createIdentifierString() we will create some compatibility issues.
If PluginDescription::matchIdentiferString() was updated so that the value of fileOrIdentifier was ignored, would that resolve the issues you’re seeing?
In other words I have a class which has that plugin ID (m_plugin_id) . Then async loading uses that exact plugin ID to load the actual plugin, which is given back to that class.
Then in debug build the class checks with jassert() that the plugin which is given to it is the actual requested plugin.
So currently the assertion complains that something is wrong, but in release build things seem to work correctly.
So debug build and release build have different behavior now.
I meant that while debug build (assertion) indicates that something is wrong, nothing is actually wrong in practise because release build has no assertions and everything loads up correctly. Hence they have different behavior. The issue is the assertion.
