createIdentifierString and shell-plugins

General JUCE discussion
1

Hi

I have an issue with the PluginDescription::createIdentifierString() function.

In my case this is related to Waves plugins on windows.

The KnownPluginList creates this string like this “VST-C1 comp Mono-11d63e7-434d504d”

(Like used in knownPluginList.getTypeForIdentifierString())

But when I call

AudioPluginInstance:: getPluginDescription().createIdentifierString()

It returns “VST-WavesShell-VST 9.2-11d63e7-434d504d”

Any ideas, is this just me?

2

IIRC either one will work, it's the two ID numbers at the end that are important when reloading the plugin.

3

Ok then I have misunderstood something.

When I store my app’s settings I save the string I get from

AudioPluginInstance:: getPluginDescription().createIdentifierString()

Then when the app should load the saved plugin I pass the saved string to

PluginDescription* knownPluginList.getTypeForIdentifierString(typeId);

I then load the plugin based on the description returned.

The thing is that this does not work as the strings are different and the getTypeForIdentifierString function simply compares the string.

Is there a better(correct) way to store and recall the plugin type?

4

Hmm, looks like getTypeForIdentifierString wasn't doing the comparison very well. Try again now..

5

Thank you, that did the trick

6

I have problem related to this.
Why does the PluginDescription::matchesIdentifierString check only the end of the identifierString? I have two Waves plugins, they are in the same shell dll file and they have the same PluginDescription::uniqueId, only the PluginDescription::deprecatedUid is different. Therefore the matchesIdentifierString method says they are identical, and the wrong PluginDescription is returned when I call the KnownPluginList::getTypeForIdentifierString.

7

Sorry, it was my fault. My custom scanner used an old JUCE version, that caused the problem. I updated the JUCE version, the uniqueId is now really unique.

1 Like