VST Error

What happends if you reset plugins list, and make a new re-scan?
 
I don't think Sonar projects use direct references on disk, just some plugins that host other plugins do that.

Now after 2nd Reset and Plug In Scan same Error, but it points again to new path X4
 
I've deleted Boost 11 Dir in X3 path.
 
The Plug In works fine! Just the error message
 
 

The CLSID is generated in part based on the path/filename - if there was a significant (and I don't know what counts as significant!) difference between the Boost installs, intentionally or otherwise, there would be a different CLSID generated.  It's not an ideal way of identifying plug-ins IMHO.

Does nobody has an Idea? I can't solve it......
 

Many of your plugins will be duplicated if you have a path for X3 and X4 because many of the plugins are available in both versions of Sonar

Maybe some general information about CLSIDs will help...
 
A CLSID is an ID that uniquely identifies a plugin. It is generated by the developer at compile time, and has nothing to do with where you've installed the DLL. Absolute pathnames only come into play when the Cakewalk Plugin Manager scans DLLs and writes an entry into the registry that correlates the CLSID with an actual file location. This is the only link between the CLSID and the DLL's path.
 
CLSIDs are used within your projects to specify plugins. When you load a project, SONAR looks up the CLSID in the registry to find out where the file is physically located. It then reads the CLSID from the DLL's file header and compares it against the CLSID that Plugin Manager had previously registered when the plugin was last scanned. If they don't match, that tells SONAR that the plugin on disk is not exactly the same as what was there when the last scan was run. Without this safety check, it's possible that loading an incompatible version of a plugin might not work right, or in extreme cases even crash SONAR.
 
Because the plugin is identified within the project only by its CLSID, you are free to move DLLs around without messing up projects - as long as you re-scan so that the registry reflects the new file locations. SONAR gets the CLSID from the CWP file, looks it up in the registry to determine where the file is, and loads it from the new location without any fuss.
 
Developers try to re-use the same CLSID for different versions of the plugin for compatibility. For example, say you have version 1.0 and version 1.0.1 of the same plugin that are functionally identical except for some bug fixes and therefore are mutually interchangeable. The developer will therefore use the same CLSID for both versions and the DAW will not be able to distinguish one from the other. This is why plugin upgrades are usually painless - as far as the DAW is concerned, as long as the CLSID doesn't change it's still the same plugin.
 
If the plugin has new features, though, the dev may elect to assign a new CLSID to the new version. If the new DLL is subsequently installed into the same location as the old one, you now have a mismatch between the CLSID saved in the registry and the real CLSID baked into the file. If this occurs, SONAR helpfully warns you that the file you're loading is not the same one you were using when you created the project originally. More often than not, the plugin still works, but the warning is there because SONAR doesn't know if the new plugin will work or not.
 
The problem you're having is a side-effect of having duplicate plugins with different versions and different CLSIDs. SONAR looks up the CLSID in the registry, navigates to its location and reads its internal CLSID, sees they don't match and says "whoa! that is NOT the same DLL I expected".
 
Your best long-term strategy is to use a single location for all your plugins, or at least a limited number of locations, so that you can more easily eliminate duplicates. You might encounter some "missing plugin" messages when you load old projects. The only cure for that is to remove the plugin and then re-insert it. Yes, that's a hassle. You may have to save the plugin's settings as a preset before removal and then use that preset to restore the settings after re-insertion.
 
But it's worth the aggravation to get it set up correctly now and avoid hassles down the road. 
 
 
 
 
 
 
 

bitflipper
A CLSID is an ID that uniquely identifies a plugin. It is generated by the developer at compile time, and has nothing to do with where you've installed the DLL.

Hey Dave, I would agree with the above, but I believe Kevin might be right that the CLSID generated at compile time is based on the file name.
 
This would explain the issue with Boost11, specifically, because the 8.3 "DOS" name for the 32-bit plugin (BOOST11.DLL) is different from the 64-bit plugin (BOOST1~1.DLL) because the 64-bit plugin's long name (Boost11_64) exceeds 8 characters and has to be truncated while the 32-bit version's does not.
 
Most plugins have names that already exceed 8 characters without "_64" or a similar identifier appended to the x64 version, so both versions truncate to the same 8.3 name, generating the same CLSID.
 
 

It's based on the filename...
 
I took Channel Tools (64 bit) as an example.
 
Channel Tools.dll -> {141AC902-4357-706E-4348-414E4E457E31}
Rename to CTools.dll -> {141AC902-4357-706E-4354-6F6F6C730000}
 

KPerry
It's based on the filename...
 
I took Channel Tools (64 bit) as an example.
 
Channel Tools.dll -> {141AC902-4357-706E-4348-414E4E457E31}
Rename to CTools.dll -> {141AC902-4357-706E-4354-6F6F6C730000}
 
 

Interesting. So it's not even built in to the DLL; it's generated dynamically by the O/S...?
 
That makes me curious; what happens if you rename to Channe~1.dll?

KPerry
It's based on the filename...
 
I took Channel Tools (64 bit) as an example.
 
Channel Tools.dll -> {141AC902-4357-706E-4348-414E4E457E31}
Rename to CTools.dll -> {141AC902-4357-706E-4354-6F6F6C730000}
 

Very bizarre, unexpected and illuminating! 
 
I tried this with bitmeter.dll, which I renamed bitflipper.dll and then ran a re-scan. The CLSID changed from {141AC902-6774-4357-4269-744D65746572} to {141AC902-6774-4357-4249-54464C497E31}.
 
Scrolling through several plugin keys, I noted that they all begin with 141AC902... which would certainly not be the case if each vendor was assigning a GUID. These numbers are apparently generated by the Cakewalk Plugin Manager at scan time. They may not even be globally unique identifiers.
 
I renamed the file again, this time calling it bitmeter.dll (rather than BitMeter.dll) and got yet another CLSID. Not only is it based on the filename, it's case-sensitive. After renaming back to its original name, it once again acquired the same CLSID. It appeared as though the last 16 bytes are based entirely on the filename.
 

---

UPDATE: it isn't just based on the filename, it IS the filename. Expressed in hexadecimal.

---

Thinking about it further, it occurred to me that these probably were GUIDs back when SONAR only supported DX, and when they added the VST wrapper they started generating their own pseudo-GUIDs so that code wouldn't have to be re-written for VST support.