This is an ongoing issue I've had with Sonar over the years and maybe they fixed it in X3, but its still haunting me in X2. Often if I open an old project from a previous OS/Sonar installation in Sonar it will consider some of my VSTs as missing despite there being versions of these VSTs installed. I realize there are many factors that can cause Sonar not to recognize the installed VST as the same as the older one (though in my case they are sometimes the same version).
 
Is there perhaps a way to find out the ID and file path associated with a missing plugin to help troubleshoot why it thinks its missing?
 
Is there still no way to make Sonar take the settings from the missing VST and apply them to the installed working VST if they are basically the same?
 
Thanks.

Without the previous installation available, I know of no way to carry forward information or presets from plug-ins that have changed identities between versions. From SONAR's perspective the plug-ins are totally different. If the presets were exported, they could be imported into the new version of the plug-ins assuming the new version understands the old plug-in preset data.

For me this is just bad plugin design.
i.e. Rapture and Dimension LE vs the full versions, really we should be using the same DLL's just different serial numbers rather than a different codebase, can't do much though from 32 bit to 64 bit.

CakeAlexS
For me this is just bad plugin design.
i.e. Rapture and Dimension LE vs the full versions, really we should be using the same DLL's just different serial numbers rather than a different codebase, can't do much though from 32 bit to 64 bit.

If the LE and full versions were not different plug-ins then those using the LE version to save CPU when necessary would loose the ability to switch between versions.

I don't know how Sonar stores the vst data for a project, but I would think that you could remap the values from the missing vst to the new vst, a sort of "At Your Own Risk" function.

It is an interesting feature request. The fun would really start when a few parameters don't line up, have been re-purposed or have slightly different ranges.

scook

CakeAlexS
For me this is just bad plugin design.
i.e. Rapture and Dimension LE vs the full versions, really we should be using the same DLL's just different serial numbers rather than a different codebase, can't do much though from 32 bit to 64 bit.

If the LE and full versions were not different plug-ins then those using the LE version to save CPU when necessary would loose the ability to switch between versions.

I'm not sure I understand this. The point is you use the same code version so you don't need to switch between versions. If you design it well enough you would just have certain features locked or unlocked depending on the serial number, features not being used will not take up any extra CPU.,.. Melodyne does this for example.... 

scook
It is an interesting . The fun would really start when a few parameters don't line up, have been re-purposed or have slightly different ranges.

Thus "At Your Own Risk" :)

CakeAlexS

scook

CakeAlexS
For me this is just bad plugin design.
i.e. Rapture and Dimension LE vs the full versions, really we should be using the same DLL's just different serial numbers rather than a different codebase, can't do much though from 32 bit to 64 bit.

If the LE and full versions were not different plug-ins then those using the LE version to save CPU when necessary would loose the ability to switch between versions.

I'm not sure I understand this. The point is you use the same code version so you don't need to switch between versions. If you design it well enough you would just have certain features locked or unlocked depending on the serial number, features not being used will not take up any extra CPU.,.. Melodyne does this for example.... 

Anti-piracy measure probably.

> Anti-piracy measure probably.
 
If so, flawed...