Thanks for the feedback, I think the suggested change sounds sensible. A collision would imply that the fileOrIdentifier matches between the two colliding plugins, but I think it’s very unlikely that a user would replace a plugin with an incompatible plugin with exactly the same name + path + uniqueId/deprecatedUid.
1 Like
Great! Thanks 
I’m having some issues with Waves plugins not working after these changes. If a user doesn’t rescan their plugins, then all the uniqueID in KnownPluginList will be 0. And all the deprecatedUid will still be correct. But when trying to load a VST2 shell plugin, only the unqueID is used, so the incorrect shell plugin is loaded in VSTPluginFormat::createPluginInstance. There are other places the unique id is used, like in LADSPAPluginFormat::createPluginInstance that also need to be updated to use either ID.
bool PluginDescription::matchesIdentifierString (const String& identifierString) const
{
const auto matches = [&] (int uid)
{
return identifierString.endsWithIgnoreCase (getPluginDescSuffix (*this, uid));
};
return matches (uniqueId) || matches (deprecatedUid);
}
Also, this should fail if uniqueId is 0. Since if the user doesn’t rescan their plugins, all uniqueIDs will be 0 and any saved descriptions will have a uniqueID of 0, so things that shouldn’t match will get matched.
Thanks for reporting. I can reproduce the issue, and will push a fix shortly.
I don’t understand this issue. As long as the identifierString argument isn’t generated using an id of 0, this function will work as expected. Old plugin description strings (such as those found in the KnownPluginList) have been created using the deprecatedUid, and will not be zero. It sounds like you might be calling createIdentifierString on a PluginDescription loaded from old XML, and then matching this string against other PluginDescriptions also loaded from old XML. In this case, I’m not sure whether changing matchesIdentifierString is the right fix. It would be confusing if an identifier string with a uid of 0 failed to match a PluginDescription with a uid of 0. Perhaps createIdentifierString() should use the deprecatedUid instead of the uniqueId in cases where the uniqueId is 0. Would that solution work for you?
That would work. For now I have worked around it by always generating old style identifier strings.
The issue I’m seeing is that only the deprecated uid is saved in the scanner settings – so all the uniqueId values are zero unless you go through and call VST3 createPluginDescription() which only happens when you instantiate a plugin. This means that new presets which use createIdentifierString() don’t recall.
Shouldn’t the scanner save both the old deprecated uid and the new uniqueId in the settings XML so the uniqueId gets initialized?
Rail
I think the KnownPluginList calls PluginDescription::createXml to generate the xml for each element, and this should include the new uid under the uniqueId name. This field won’t be present for lists that were generated before the uniqueId change, though.
Are you seeing that the uniqueId field is being set to 0, even when re-scanning using the current version of JUCE?
I think I confused myself… I built a debug version of the AudioPluginHost but scanning failed because of the PluginAlliance protection… so I scammed with a release build I had on my desktop which I figured out was built with an older version of JUCE… so it didn’t add the uniqueId name to the xml… but I saw it’s in PluginDescription::createXml() – just not where I expected it to be (next to the “uid”).
We’re worried the customer base won’t rescan for the update… so I’m gonna use the older uid if the uniqueId is zero… or if it’s an older preset with an older identifierString.
This was the biggest headache in updating JUCE BTW.
Rail
This solution seems to work for me as well.
I wonder if there is a certain reason why this is still not integrated into the JUCE repository. Have you found some other issues that could be caused by this change?
I think this probably just fell off my radar somehow. Added here: