BUG: Some VSTi plug-in properties need to be re-set on new and opening projects

[JohnK]

I have a VSTi that needs the "Enable delay compensation" set. When I select / set this property for a VSTi, it is lost on closing the project and/or opening a new project, including re-opening this same project. i.e. It appears to not be saved and reloaded. I would expect this property to be a system wide setting for the VSTi.

I also use JBridge for another VSTi, and I note that this setting IS saved between sessions/projects/startups and on new instances. i.e. it acts as a system wide setting as expected.

I have not checked/thought about any other settings on this page, but as a concept of where these settings are, I would of expected all these settings to be system wide and automatically set on every startup and use of the VSTi.

Edited August 21, 2020 by John Kalabric

[Starship Krupa]

Remind me John, I know you talked about this at length in the Free Instruments thread: is this for all of your VSTi's? Was it only 64-bit or only VST2's? I can't remember.

This isn't happening on my systems, so something probably somehow got ganked on your installation.

Cakewalk stores most of its settings like this in AUD,INI, which is in your C:\Users\<yourusername>\AppData/Roaming\Cakewalk\Cakewalk Core folder.

Try renaming this file and restarting Cakewalk and see if the issue persists.

[JohnK]

2 hours ago, Starship Krupa said:

Remind me John, I know you talked about this at length in the Free Instruments thread: is this for all of your VSTi's? Was it only 64-bit or only VST2's? I can't remember.

This isn't happening on my systems, so something probably somehow got ganked on your installation.

Cakewalk stores most of its settings like this in AUD,INI, which is in your C:\Users\<yourusername>\AppData/Roaming\Cakewalk\Cakewalk Core folder.

Try renaming this file and restarting Cakewalk and see if the issue persists.

i have been meaning to come back to this thread and post the following information, as the user Kurre (I should learn how to do a mention in this forum) appears to have honed in on the problem.

After reading his tests, I checked mine, and found the exact same behavior. That is, the settings are not re-loaded on 32b VSTi's but are restored for 64b vsti's.

Since there is now a logic/repeat-ability to the behavior, and it does work on 64b VSTi's. At this stage, I am assuming my install is OK, and it is possibly a bug in Cakewalk. I have yet to see if there are any clues in my INI file.

[Starship Krupa]

Okay, probably why I might have missed it, I've finally gotten to the point where I can pretty much go all-64 bit for my VSTi's in new projects. I keep some 32's around so I can reinstall them if older projects need them. I'll give it a look.

So I need to:

1. put a 32-bit VSTi in a project

2. check its properties to see if delay compensation is enabled, and if not, enable it

3. Save and exit the project

4. reload the project

5. check its properties again to see if delay compensation is still enabled

That should do it?

To do a mention, just type an "@" sign and then start typing the username you want to mention. The board will present you with a list of names that match your entry, and it will come out like so: @Kurre.

[Starship Krupa]

Ay-yi-yi.

Worse than you thought, John. Have you just been assuming that Cakewalk was accepting the setting? If so, try making the setting, closing the plug-in UI (or Plug-in Manager, whichever you're using to make the setting), and then reopening the Properties page for that plug-in.

On my system at least, when I do that, the box is unchecked. I didn't test anything to see if there was weirdness with delay, but, definite bug here.

What I would call it is "Cakewalk is not accepting the plug-in delay compensation setting for 32-bit plug-ins."

[JohnK]

1 hour ago, Starship Krupa said:

Okay, probably why I might have missed it, I've finally gotten to the point where I can pretty much go all-64 bit for my VSTi's in new projects. I keep some 32's around so I can reinstall them if older projects need them. I'll give it a look.

So I need to:

...snip...

That should do it?

To do a mention, just type an "@" sign and then start typing the username you want to mention. The board will present you with a list of names that match your entry, and it will come out like so: @Kurre.

Clearly you found how to reproduce the issue. And that it was so easy for you, you can see my surprise when I found it that no-one else had noticed such a core issue.

As for the mention system, that's what I expected, as its the same from another forum I frequent. But when I tried it (ie one time), it didn't work. Most likely due to either my impatience OR my very restrictive firewall I have setup.

58 minutes ago, Starship Krupa said:

Ay-yi-yi.

Worse than you thought, John. Have you just been assuming that Cakewalk was accepting the setting? If so, try making the setting, closing the plug-in UI (or Plug-in Manager, whichever you're using to make the setting), and then reopening the Properties page for that plug-in.

On my system at least, when I do that, the box is unchecked. I didn't test anything to see if there was weirdness with delay, but, definite bug here.

What I would call it is "Cakewalk is not accepting the plug-in delay compensation setting for 32-bit plug-ins."

The way I found it (and you can manually do it to actually experience the delay) was that once I had a crash/audio halt when adding a VSTi or starting cakewalk, and Cakewalk recovered by automatically, without my knowledge, bumping out my buffer to something like 40ms; I was mixing down so I didn't notice any latency playing a VSTi. All of a sudden my drums (which were a 64b VSTi) where audible ahead of the rest of the tracks (32b VSTi's). At 3ms, I can only hear it now because I am listening out for it. It's so bad its embarrassing I did not notice it before!

For me, if I made the settings, closed the properties page, and re-opened it, it had stuck. And the audible delay would be gone and stayed gone. UNTIL I opened a new project or re-opened cakewalk. Remember, 40ms makes it very audible, without explicitly checking the setting.

As for naming it, I have not checked if any of the other settings are also not being carried through on 32b VSTi's. It could be even worse than your Ay-yi-yi

Edited August 27, 2020 by John Kalabric

[Noel Borthwick]

This is not a bug. Delay compensation is not supported for synths because synths are always rendered just in time. They wouldn't be much point having synths that have delay would there?

All the Enable delay compensation flag does is allow turning off delay comp at an effects level. Its a leftover from years ago and not something most users will ever need to set. Turning it off will  make things go out of sync. 

We already have a PDC override feature in CbB for the cases that delay comp needs to be overriden so this manual setting is obsolete. 

[JohnK]

11 hours ago, Noel Borthwick said:

This is not a bug. Delay compensation is not supported for synths because synths are always rendered just in time. They wouldn't be much point having synths that have delay would there?

All the Enable delay compensation flag does is allow turning off delay comp at an effects level. Its a leftover from years ago and not something most users will ever need to set. Turning it off will  make things go out of sync. 

We already have a PDC override feature in CbB for the cases that delay comp needs to be overriden so this manual setting is obsolete. 

I think you should have a word  to your colleague, who clearly disagrees with you.

And it is DEFINITELY used by VSTi's. If you push your buffer/latency up above 40ms and turn it off for 1 VSTi (32b) and leave it on for the rest (64b). The timing issue is impossible to miss; thats how I found it. What I dont fully understand (not that thats an argument for anything) is why you would ever turn it off.

Edited August 28, 2020 by JohnK

[scook]

Just another reason to follow the plug-in makers lead and forget about the 32bit plug-in.

 

[Starship Krupa]

On 8/27/2020 at 7:47 AM, Noel Borthwick said:

this manual setting is obsolete

Perhaps, in light of the confusion we've had, it could be removed from the Properties page for VSTi's?

[Starship Krupa]

19 hours ago, scook said:

Just another reason to follow the plug-in makers lead and forget about the 32bit plug-in.

While I definitely agree with this practice for use in new projects, there's the  common scenario of wanting to mix or augment a project that was started years ago. The person may have used a unique, no longer produced instrument only available in 32-bit form,  and/or may even have been running SONAR on an older 32-bit version of Windows.

In some genres, it's impossible to migrate or start over with another instrument. because improvisation with the instrument is the composition. Ambient and drone, for instance.

So I have sympathy for those dealing with 32-bit VSTi's, especially in those scenarios. Using them in new projects....not the best idea.

[scook]

The best solution for migrating 32bit projects is opening them in a 32bit DAW and replacing the plug-ins will ones that have 32 and 64bit versions.

One can run pretty old 32bit Cakewalk DAWs on Win10.

Time is running out though. Some plug-in manufacturers have stopped producing 32bit products entirely.

 

 

[Starship Krupa]

2 hours ago, scook said:

ones that have 32 and 64bit versions.

True, that is the best solution. There are of course those one-of-a-kinds, like HG Fortune's stuff, (built in SynthEdit, the blessing and later curse of independent synth developers), and since Mr. Fortune passed in 2014, they are unlikely never be available in 64-bit.

There are some developers that I wish would stop shipping 32-bit versions, if only because their installers spew them all over the place on my system.

[scook]

I don't know of a single SynthEdit development ever ported to 64bit. For synths stuck at 32bit the solution is easy, render the audio.

There are some 32bit plug-ins that have 64bit jBridge wrappers though. It is a service provided by jBridge. Dedicated wrapper or not, it is still an extra layer of buffering and code that must be dealt with by the 64bit host.

 

[Starship Krupa]

I've started seeing a trickle of freeware 64-bit VSTi's showing up at KVR that bear the "Made with SynthEdit" logo. I don't know anything about SynthEdit except that it was a popular development tool for small shops for a while, and at one point, seemed like an abandoned project. That break in its development happened right when it was time for 64-bit plug-ins to become essential, and SynthEdit couldn't build them.

Now it would appear that there's a version of SynthEdit that can make 64-bit plug-ins and I wonder if that old code can now be used to build 64-bit versions.

[scook]

Yes, 64bit SynthEdit took a while but the latest version does produce 64bit VST2/3 and AU plug-ins. There appear to be a few differences between the last 32bit only version that may slow porting of old projects.