Problems with MSVC and host "caches"

[Fender19]

While developing a new plugin I make changes to the code; clean and rebuild the plugin; copy the new files to plugin folders and re-start my test DAW(s) with a plugin re-scan.

Everything SHOULD be clean and new, right?

Well - sometimes I get weird results - like commented-out functions still showing up as being called, outputs that CANNOT possibly occur with the current code, etc.

It seems like plugin "stuff" is being cached in many places besides the obvious ones. Some hosts, like Cakewalk, seem to be REALLY bad with this with remnants of old plugin versions still in it's memory even when completely deleted from the plugin folders!

Has anyone else come across this? It's quite maddening! Any advice on how best to "clean" everything along the way?

[BlueprintInc]

Only experienced this with shell plugings in a few hosts, but they offer a "rescan shell" button or so. Else it may have occured once or twice but was a fault of mine with copying.

If the binary changed, hosts figure this out. If your plugin was blacklisted before you might clean the blacklist first.

[quikquak]

I've had something like this with Logic Pro before. Had to do a reboot to make it forget the plug-in properly. Can't remember the specifics.
Also make sure you're actually updating the plug-in in the place the host looks. It's surprisingly easy to fall foul of that one sometimes -

[Fender19]

I've had something like this with Logic Pro before. Had to do a reboot to make it forget the plug-in properly. Can't remember the specifics.
Also make sure you're actually updating the plug-in in the place the host looks. It's surprisingly easy to fall foul of that one sometimes -

Yes, AFAIK,AU plugins on OS 10.13+ require reboot. I always reboot and run Auval as my first step in testing on Mac.

And yes, I have, on occasion, been testing a VST then realizing I had only updated the VST3 version, etc.

But what I’m talking about here is when either something in MSVC isn’t cleaning like it should be and/or the test DAW doesn’t refresh like it should. You load a newly compiled plugin and get old results. Not sure what causes that. Sometimes a reboot helps, other times not. Something gets “cached” somewhere...

[stratum]

But what I’m talking about here is when either something in MSVC isn’t cleaning like it should be and/or the test DAW doesn’t refresh like it should. You load a newly compiled plugin and get old results. Not sure what causes that.

Unless your computer clock runs backward MSVC doesn't do that. At least not unless you write a buggy makefile.

[Fender19]

Unless your computer clock runs backward MSVC doesn't do that. At least not unless you write a buggy makefile.

So how do you explain what me and two others who replied here have experienced? And, BTW, MSVC is not 100% innocent. Here’s a few examples from others on that:

https://developercommunity.visualstudio ... hould.html

https://superuser.com/questions/382319/ ... ot-working

https://stackoverflow.com/questions/469 ... -old-build

[BlueprintInc]

Which Visual Studio version are you running (your example were from 7 years back up to 2 )? All project dependencies are set correct? Did you setup custom output/intemediate paths which might conflict in any way? Do you have additional software running which might lock some files for some time and make them unaccessable for MSVS? Like I has some codesign tool running once, which prevented our copy mechanisms from overriding it with a new build...

[Fender19]

Which Visual Studio version are you running (your example were from 7 years back up to 2 )? All project dependencies are set correct? Did you setup custom output/intemediate paths which might conflict in any way? Do you have additional software running which might lock some files for some time and make them unaccessable for MSVS? Like I has some codesign tool running once, which prevented our copy mechanisms from overriding it with a new build...

I’m using the latest version of Community 2017. The examples linked above were history of other people having similar issues, not necessarily with the same version.

And this is not a diss on MSVC. Like I said I have seen DAWs do this too. Something in my system is not always clearing out when I update a plugin. Just wondering if anyone else here has experienced this and knows the cause(s). Thank you for the suggestions.

[Vokbuz]

Has anyone else come across this? It's quite maddening! Any advice on how best to "clean" everything along the way?

What is your build process? If you put new binary at the same path then it is simply impossible to restart DAW and get it loading old binary. Plugin cache does not move or copy files to secret locations, it simply stores paths to plugins because scanning plugins is time consuming. If you put new binary in new location, leaving the old one in its place, you make DAW find several copies of the same plugin. What will DAW do with it depends on the DAW.

Yes, AFAIK,AU plugins on OS 10.13+ require reboot. I always reboot and run Auval as my first step in testing on Mac.

Never had to reboot to test my AU plugin. Everything works perfectly if there are no plugin duplicates. You need to revisit your build process, it seems that it is the source of the problems.

[stratum]

Unless your computer clock runs backward MSVC doesn't do that. At least not unless you write a buggy makefile.

So how do you explain what me and two others who replied here have experienced? And, BTW, MSVC is not 100% innocent. Here’s a few examples from others on that:

https://developercommunity.visualstudio ... hould.html

https://superuser.com/questions/382319/ ... ot-working

https://stackoverflow.com/questions/469 ... -old-build

I have seen the bug mentioned in the first two and it doesn't cause the same problem. For the last, I haven't seen it.

[davidguda]

Do you switch between debug and release build, maybe starting the wrong one.
Same with 32/64 bit, rebuilding 32 bit when testing 64 bit is pointless etc.
I've fallen for those a couple of times.

[Fender19]

Do you switch between debug and release build, maybe starting the wrong one.
Same with 32/64 bit, rebuilding 32 bit when testing 64 bit is pointless etc.
I've fallen for those a couple of times.

It seems the cause of this problem is that many DAWs "cache" plugin data. Just had an issue yesterday where I revised a plugin and after restarting both Cubase and Cakewalk showed the old version (which did not even exist in the vst folders). After a forced rescan of plugins the NEW version showed up.

So, simply overwriting the .dll or .vst3 file and restarting the host does not always refresh it.

[Vokbuz]

So, simply overwriting the .dll or .vst3 file and restarting the host does not always refresh it.

It sounds ridiculous. If you replace the binary, it is impossible for host to load old one.

[Fender19]

So, simply overwriting the .dll or .vst3 file and restarting the host does not always refresh it.

It sounds ridiculous. If you replace the binary, it is impossible for host to load old one.

I can assure you it IS possible - I have seen it happen more than once. As I said here it happened yesterday. I compiled a revised plug, copied the .vst3 to the folder, started up Cakewalk and NONE of the changes I made were there. Cleared the VST folders and did a forced rescan - NOW the plugin changes showed up. I have seen the same thing happen in Wavelab.

[mike_the_ranger]

If all my DAWs copied all my plugins to a secret cache that would be a lot additional disc space in use Very unlikely...