BR: PluginDescription::uid for VST3 don't match between windows and macOS

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 :+1:

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.