Cakewalk/UAD plugins issue

[jono grant]

Hi there, I've been back and fourth with Universal Audio, complaining about an issue with their recent updates (last two updates)

When UAD updates a plugin, they change the name of it. So, a "Neve 33609" compressor gets renamed to "Neve 33609c".

Because the name has changed, Cakewalk will not open the Neve 33609 in older session files because Cakewalk identifies plugins by their name rather than a plugin ID#.

I was complaining to UAD over and over that they shouldn't be renaming plugins, however they came back to me saying the problem is independent to Cakewalk because it uses the plugin title rather than the plugin ID#. They don't have complaints from other DAWs with this issue.

This is a huge drag because it means Cakewalk/UAD users can't update their plugins or Cakewalk will not open older sessions that contain that particular plugin.

It's something Cakewalk needs to fix. 

How can I bring this to the attention of the right person at Cakewalk?

Cakewalk needs to work properly with UAD, it's one of the best systems around (agree or not)

Perhaps there is a workaround, not sure, i don't think renaming does anything.

Who can I tag or where can i post this issue so that someone sees it?

Thanks

jono

 

 

[John Vere]

I think the Feature Request sub forum is the place you get best responses 

[Steev]

When you updated your UAD plugins the installer uninstalls the older version and replaces with the new. 

You most likely need to rescan your VST plugins so CbB can find the new plugin version, and all will be well again.

[scook]

There are a few issues with this setup though

1) Do not have nested paths in the scan path.

The image shows both "C:\program files (x86)\vstplugins" and  "C:\program files (x86)\vstplugins\eventide"

The second path is unnecessary as any path under "C:\program files (x86)\vstplugins" will be scanned. 

Having redundant paths causes unnecessary work for the scanner and has caused scan errors in the past.

 

2) Do not leave the "Rescan Failed Plug-ins" and "Rescan All Plug-ins" enabled.

By default, these options are off and are meant to stay off most of the time.

They cause extra work for the scanner which can lead to scan failures.

These are intended to be used to resolve specific one-off scanning problems.

Once a scan is run with these options, they should be turned off.

Running both options at the same time is functionally the same as a VST Reset.

 

3) Enable Scan in sandbox.

By default, this is enabled. This was added to improve the safety and reliability of the scanner.

[Xoo]

Couple of things:

1 - Have you (intentionally or unintentionally) disable 8.3 file naming on the drive where your VST dll's are stored?  For historical reasons, Cakewalk needs the 8.3 file naming to be enabled (https://www.tecklyfe.com/windows-server-tip-disable-8-3-naming-strip-existing-short-names/#:~:text=To disable 8.3 naming system-wide%2C run the following,short names%3A fsutil.exe 8dot3name strip %2Fs %2Fv D%3A).  NTFS can do funky things with 8.3 names even if you delete a file and copy a new one with what should be the same 8.3 name back in, if you do it quickly enough, Windows gives it a new 8.3 name...

2 - Given the above, have you tried uninstalling and then re-installing, rather than updating, which might create the same 8.3 name for the new file (if it's essentially the same filename/8.3 name(?

3 - There's no central registry for VST IDs, so there's merit in using the filename (else you could end up with 2 different VSTs with the same ID...what to do then?), but there's probably improvements that could be made (eg. use filename to disambiguate if you have 2 dll's presenting the same ID).  But that would possibly(?) break backwards compatability, and we know how good Cakewalk is with that.

4 - It's probably possible to hack the relevant registry keys to make it work, but you'd likely have to do it every VST scan (definitely if you do a full rescan):

HKEY_CURRENT_USER\SOFTWARE\Cakewalk Music Software\Cakewalk\Cakewalk VST X64\Inventory

DosName, FullName andFullPath are probably the values that would need to be tweaked within the plug-ins key.  But I can give no guarantees of what would/wouldn't happen, so do so at your own risk.

[Will.]

I've got a fellow mixing engineer that has the same problem with UAD plugins in Cakewalk. These answers look promising - I'll pass this on to him. 

Edited June 21, 2021 by Will_Kaydo

[Tommy Byrnes]

I've found the best way to deal with UAD plugin problems like this, and many other VST problems as well, is to make sure I only have one VST2 folder location, which for me is Cakewalk\VST Plugins. Have the VSTScan only scan that one folder. I've always used that location, no matter the DAW just because I've been doing it since the early Sonar days. VST3 defaults to its normal place (C:\Program Files\Common Files\VST3). I copy (don't cut) the dll for the plugin I own from the main UAD Powered Plugins folder and paste them into a new UAD Plugins folder in my main VST2 folder and there they stay, unaffected, unless I buy an update for one of them or there are fixes to specific plugins. This way the VST folder and their contents aren't changed and there aren't all the UAD plugins to scan, just the ones you own.

Just don't scan the normal UAD folder and you're good. Keep the UAD Powered Plugins folder intact because Console uses that location to load the plugins.  I hope this helps.

(edited for a stupid spelling error)

Edited June 21, 2021 by Tommy Byrnes

[Noel Borthwick]

>>Because the name has changed, Cakewalk will not open the Neve 33609 in older session files because Cakewalk identifies plugins by their name rather than a plugin ID#.

I'm not sure where you got that from. Cakewalk has always utilized the plugin ID. However for VST2 plugin its not sufficient to do so (because the ID is not guaranteed to be unique and many vendors make mistakes). So we use an expanded ID scheme that utilizes part of the file name (in this case its the 8.3 file name). Many years ago I improved on this to be less dependent on 8.3 file names. However you must save your projects with the plugins for this scheme to kick in. If you have old projects they will not benefit from this obviously. 

Also look into the details that Kevin posted above. If the session isn't opening its because the something more drastic changed in the name resulting in the ID's not matching. We don't have any UAD plugins in-house to test this with. Are the plugins still tied to UAD hardware?

If you send a dump of your VST inventory from the registry and a sample project file that won't find the plugin, I can take a look at why it fails to load.

[Tommy Byrnes]

41 minutes ago, Noel Borthwick said:

 Are the plugins still tied to UAD hardware?

Yes, they are, Noel

 

[Steev]

On 6/20/2021 at 1:50 PM, scook said:

There are a few issues with this setup though

1) Do not have nested paths in the scan path.

The image shows both "C:\program files (x86)\vstplugins" and  "C:\program files (x86)\vstplugins\eventide"

The second path is unnecessary as any path under "C:\program files (x86)\vstplugins" will be scanned. 

Having redundant paths causes unnecessary work for the scanner and has caused scan errors in the past.

I had purposely added the "C:\program files (x86)\vstplugins\eventide" path because SONAR/CbB misses some of my "Eventide" plugins and doesn't register them all. And that may be a good idea to do for UAD plugins as well, as the UAD primarily runs it's FX in it's own ecosystem and only supports computer based VSTs which I found to create conflicts. I had so many recurring problems running UAD on my Windows computer I just gave up and confined the Apollo 8 system to my Mac where is benefits are sorely needed and appreciated.? With the advancements in today's current multicore x64 bit CPU's, VST 3 & ASIO tech, particularly with UA's main arch nemesis "WAVES", hardware accelerated  hybrid systems such as Apollo aren't as necessary as they once were with x32 bit Windows. And as far as front end (channel strips) go, Cakewalk's ProChannel is probably the #1 "best" overlooked channel strips in the world.

 

2) Do not leave the "Rescan Failed Plug-ins" and "Rescan All Plug-ins" enabled.

By default, these options are off and are meant to stay off most of the time.

They cause extra work for the scanner which can lead to scan failures.

These are intended to be used to resolve specific one-off scanning problems.

Once a scan is run with these options, they should be turned off.

Running both options at the same time is functionally the same as a VST Reset.

That's a great idea if you allow CbB's default settings to scan for VSTs every time it starts. But I turned off the "Scan plugins every time CbB boots" by default because that in itself is a lot of unnecessary work and adds a few seconds to a minute to boot times. The only time I run VST scans is when I add a new plugin or update existing plugins, which is very seldom compared to every time I start my DAW. And being my main purpose for CbB is creating music projects, I don't frequently experiment with trying out every new plugin I read about in endless cycles of install/uninstall, my Windows registry stays relatively lean & clean, CbB and all plugins I do have installed runs rock solid and stable, and I don't have 1/10th the problems of those that do.

 

3) Enable Scan in sandbox.

By default, this is enabled. This was added to improve the safety and reliability of the scanner.

Yes, I have mixed feelings about that, and I'm sure that "helps" when installing outdated plugins and any software obtained from dubious sources but does really improve  the safety and reliability of CbB if it's not running in a sandbox? ?

 

 

 

 

Edited June 22, 2021 by Steev

[Tom B]

My UAD software is two versions behind the current version.  I have the older "UAD Neve 33609" (inactivated).  I'm wondering whether my older registry data might be helpful in understanding the update problem with the current "UAD Neve 33609c" experienced by Jono.

If helpful, I'll post the pertinent data for the plugin such as:  DosName, UniqueId, Path Name, etc.  I'm running UAD V9.12.

I've been delaying updates for UAD software because of a similar issue regarding the newly updated and enhanced UAD 'API Vision Strip'.  Eventually, I'll  update.

[jono grant]

On 6/20/2021 at 1:50 PM, scook said:

There are a few issues with this setup though

1) Do not have nested paths in the scan path.

The image shows both "C:\program files (x86)\vstplugins" and  "C:\program files (x86)\vstplugins\eventide"

The second path is unnecessary as any path under "C:\program files (x86)\vstplugins" will be scanned. 

Having redundant paths causes unnecessary work for the scanner and has caused scan errors in the past.

 

2) Do not leave the "Rescan Failed Plug-ins" and "Rescan All Plug-ins" enabled.

By default, these options are off and are meant to stay off most of the time.

They cause extra work for the scanner which can lead to scan failures.

These are intended to be used to resolve specific one-off scanning problems.

Once a scan is run with these options, they should be turned off.

Running both options at the same time is functionally the same as a VST Reset.

 

3) Enable Scan in sandbox.

By default, this is enabled. This was added to improve the safety and reliability of the scanner.

Hi scook, that screen shot is from another gent that commented on the post, not from me (OP Jono) I have my vst setup as you describe, no redundant folders etc. Sandbox, yes and no checks on rescan failed or all plugins. Don't think it's that. Gonna go through the rest of the comments. Thanks. J

[jono grant]

On 6/21/2021 at 4:12 PM, Noel Borthwick said:

>>Because the name has changed, Cakewalk will not open the Neve 33609 in older session files because Cakewalk identifies plugins by their name rather than a plugin ID#.

I'm not sure where you got that from. Cakewalk has always utilized the plugin ID. However for VST2 plugin its not sufficient to do so (because the ID is not guaranteed to be unique and many vendors make mistakes). So we use an expanded ID scheme that utilizes part of the file name (in this case its the 8.3 file name). Many years ago I improved on this to be less dependent on 8.3 file names. However you must save your projects with the plugins for this scheme to kick in. If you have old projects they will not benefit from this obviously. 

Also look into the details that Kevin posted above. If the session isn't opening its because the something more drastic changed in the name resulting in the ID's not matching. We don't have any UAD plugins in-house to test this with. Are the plugins still tied to UAD hardware?

If you send a dump of your VST inventory from the registry and a sample project file that won't find the plugin, I can take a look at why it fails to load.

Hey Noel, UAD support made the assumption it might have to do with plugin #ID. Cakewalk is the only DAW they've had reports on this issue. Other DAWs are not having the issue. 

Don't understand all the 8.3 file name info, sorry. 

The sessions are opening fine, they just won't open the updated plugin (that has a new name)

When I say old files, I mean files that could be from yesterday, I don't mean ancient files. I use that Neve compressor on everything across a zillion sessions, so I really need a work around for this. I do tv/film and album production, projects can go on for years.

I clicked on the vst inventory folder from the registry and clicked on export. Hope that's what you mean by a dump. I'll attach it here.

I'll need to reinstall the whole UAD firmware and update in order to show you that CW won't open the plugin and send a sample file.

I will do that soon. Here is the dump file (hopefully) *Too big to directly attach 6 MB, but here's a link on dropbox: https://www.dropbox.com/s/14v1v5k2xvwta50/VST inventory.reg?dl=0 

Trying to understand the note above about making a specific folder for UAD. Currently, they get installed to x86 prog files/steinberg/powered plugins.

[jono grant]

On 6/25/2021 at 2:03 AM, Tom B said:

My UAD software is two versions behind the current version.  I have the older "UAD Neve 33609" (inactivated).  I'm wondering whether my older registry data might be helpful in understanding the update problem with the current "UAD Neve 33609c" experienced by Jono.

If helpful, I'll post the pertinent data for the plugin such as:  DosName, UniqueId, Path Name, etc.  I'm running UAD V9.12.

I've been delaying updates for UAD software because of a similar issue regarding the newly updated and enhanced UAD 'API Vision Strip'.  Eventually, I'll  update.

I think I'm on the same UAD version 9.12.2 as that's the last version that still had the older 33609 version. Our data is probably the same

 

[Tom B]

2 hours ago, jono grant said:

I think I'm on the same UAD version 9.12.2 as that's the last version that still had the older 33609 version. Our data is probably the same

 

Yes, version UAD 9.12.2 has the older Neve 33609 version. Our registry data should be the same for UAD 9.12.2 (except, maybe path names).  

The latest UAD version is 9.14.5.  I decided to update to that version about a week ago, and now have the updated Neve 33609C.  Interestingly, my Cakewalk test project was able to automatically find the 33609C. There are a few differences in registry data for UAD 9.14.5:  The dll  is now "UAD Neve 33609 C.dll",  the DosName is different, the uniqueId (i.e. plugin ID) is the same,

My test project uses  Cakewalk 2021.04 (perhaps it started one rev earlier). I'm guessing your projects started out with earlier Cakewalk versions. 

Note:  I haven't activated the 33609 plugin because it's only being used to understand this issue.  However, I don't think that matters.  For those not familiar with UAD,  the installation includes all the VSTs  whether activated or not.  I think this is done to make it easier demo and/or purchase the plugin.  An inactive plugin can be inserted, but it isn't functional.

[jono grant]

49 minutes ago, Tom B said:

Yes, version UAD 9.12.2 has the older Neve 33609 version. Our registry data should be the same for UAD 9.12.2 (except, maybe path names).  

The latest UAD version is 9.14.5.  I decided to update to that version about a week ago, and now have the updated Neve 33609C.  Interestingly, my Cakewalk test project was able to automatically find the 33609C. There are a few differences in registry data for UAD 9.14.5:  The dll  is now "UAD Neve 33609 C.dll",  the DosName is different, the uniqueId (i.e. plugin ID) is the same,

My test project uses  Cakewalk 2021.04 (perhaps it started one rev earlier). I'm guessing your projects started out with earlier Cakewalk versions. 

Note:  I haven't activated the 33609 plugin because it's only being used to understand this issue.  However, I don't think that matters.  For those not familiar with UAD,  the installation includes all the VSTs  whether activated or not.  I think this is done to make it easier demo and/or purchase the plugin.  An inactive plugin can be inserted, but it isn't functional.

Thanks! I'll do some more digging!

Cheers

[jono grant]

On 6/21/2021 at 9:19 AM, Tommy Byrnes said:

I've found the best way to deal with UAD plugin problems like this, and many other VST problems as well, is to make sure I only have one VST2 folder location, which for me is Cakewalk\VST Plugins. Have the VSTScan only scan that one folder. I've always used that location, no matter the DAW just because I've been doing it since the early Sonar days. VST3 defaults to its normal place (C:\Program Files\Common Files\VST3). I copy (don't cut) the dll for the plugin I own from the main UAD Powered Plugins folder and paste them into a new UAD Plugins folder in my main VST2 folder and there they stay, unaffected, unless I buy an update for one of them or there are fixes to specific plugins. This way the VST folder and their contents aren't changed and there aren't all the UAD plugins to scan, just the ones you own.

Just don't scan the normal UAD folder and you're good. Keep the UAD Powered Plugins folder intact because Console uses that location to load the plugins.  I hope this helps.

(edited for a stupid spelling error)

Sorry, I'm a little confused here. Is it something like this: Perhaps if I create a special folder for UAD plugs in my cakewalk vst folder, I can just copy the plugins I want/own from the current vst folder (x86/steinberg/powered plugins) and only have cakewalk scan that folder. Then run the newer update, copy anything I want from it to that cakewalk vst folder I made and never scan the steinberg folder where it gets installed. Then it will utilize any new console updates but cakewalk only sees the plugs in the cake vst folder? Something like that? Just wondering if the update/firmware itself might not allow me to run the older plugins. hmmmm Maybe i'm way off here... thanks!