@KPerry
 
I always have 32bit Projects in 64bit Sonar, it was never a problem!
 
@mudgel
 
So, I want to deinstall X3 and remove this X3 VST DIR, but I think it would be difficult and there maybe get lost some Things in Platinum. Can I just delete this double VSTs in my X3 VST DIR? 
I have deleted Boost11 in this Dir, but still the Error....
 
Thanks,
Basie.
 

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. 
 
 
 
 
 
 
 

I learned very quickly to pay attention when installing plugins/software. I keep them ALL in the top 5 most common VST directories,and NEVER under the mfg name. Too easy to grow the search path, and with each addition the longer it takes to complete a scan. Just for grins, put in c:\ and prepare to take a nap.....

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.
 
 

I don't think the CLSID is based on the file name. [WRONG! SEE BELOW] I can compile an executable and give it any name I like, but unless I explicitly tell it not to, it'll give me the same CLSID every time regardless of the exe name. It's a compiler setting.
 
I don't remember all the details, but I do know that part of the CLSID algorithm is based on your network interface's MAC address. That's going to always be unique, because part of that number is an ID unique to the manufacturer and the rest is a serial number.
 
I have actually encountered two executables with the same GUID, from two different vendors. That's only happened once. Theoretically, the odds of it happening at all are astronomical, greater than the odds of ever resolving the question of what sample rate is best.

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}
 

@bitflipper
 
Thanks for this long answer, ok, now the only way is to Re-insert the PlugIn and save!
 
Ok, no prob at all, only a few files and only Boost11...
 
Basie
 

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?

That would probably make the CLSID the same as Channel Tools.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.