That "disappearing" plugin thing; still in C9?

Any (statically linked?) plugin can be the one to send it over the “edge” of having too many linked libraries, I believe. You wouldn’t know which one the big offender is.

It’s either that, or keep on raising the issue here, till the cows come home.

But every DAW will hit the limitation differently.

I don’t know why I didn’t find that before. I wish Windows wasn’t designed with a limit like that…

Since there are quite a lot of these threads dealing with this issue:

Any news here?

  • I do not get the “dll” thing completely - what’s up with VST3? I have these issues with VST3 plugins as well… but there are no dlls … ?

I believe .vst3 files are just renamed DLLs.

EDIT: See Fabio’s reply.

ok that was my intention as well…

@ Brandy: there are not many news, unfortunately, as I wrote elsewhere “Most work on our side is done (but still ongoing). Plug-in developers will need to load runtime libraries differently in order to fully resolve this.”

@djw: VST3 could be considered ‘container files’ which can also hold various versions of a plug-in (e.g. mono, stereo, multi-channel…a good example is Cubase’s own plug-ins set, a single file containing all of the plug-ins). Saying this without considering the different protocol, features set, etc.

Thanks, Fabio!

As we all know that for some reasons certain plugins WILL open / load when others will not, this should (at least in theory) possible to fix within the plugins?

For example I never had problems with Sonnox Plugins (and they are old!!) - I do not have problems with Cubase Stock Plugins, I never had problems with for example Waves CLA 2A - while the CLA 3A will NOT load anymore… I would be under the impression these are plugins built with the same “technique” - but I can load hundreds of 2As will 3As and most other Waves plugins will not load anymore…

I don’t think there is any other way to reverse engineer or deduct if plugins load or not, besides just testing them one by one.
The good news is you only have to worry about it once it happens and you only have to focus on the 3rd pty plugins you actually used in that project.

Another way to look at it is not to prepopulate templates with plugins and empty channels which you don’t use.
If you create templates with 32 channels and each channel has already your favorite EQ, compressor, channelstrip, VU meter and gain knob loaded, that’s already 160 plugins before you even get to work (and half might just sit there not being used)

It’s an annoyance, but by adapting the way one works, it can quite easily be avoided

Well, the problem is that the “loadable point” differs for some reasons, as others mentioned in similar threads as well… that means: 12h mixing session, everything works fine, the other day some plugins are missing because they will not load. Most likely you will not notice in bigger projects.

My projects are often about 60 min long with 500+ tracks (processing usually mainly on groups - and with VST3 processing only when there is audio this is not a problem) - but that way I run easily in this problem.

But yes, there are some strategies to not suffer tooo bad from this issue but there is no real workaround.

One strategy is even “don’t overprocess” - which might enable you to deliver better mixes with less processing, often using only basic tools like EQ/Dyn (in my case using Sonnox or Fabfilter (which btw loads fine all the time)) - without processing the sh*t out of each track using fancy saturation/coloration/vintage stuff etc…

I like the “you will not notice” in bigger projects :slight_smile: that’s a funny point, process the heck out of stuff and then don’t notice it’s turned off :slight_smile:

Well, lets have a 60 min Project with lets say 500 tracks… Track 456 is just a short sound, lets say an explosion, or some kind of percussion or just a short sample, speech or whatever - wich appears at lets say Min 46:34.

You worked 7 days on the mix, the other day you just have to do a quick modification - lets say adjusting some vocal automation in the first half of that session… You will now export the whole thing again. Will you notice that this slap-back delay on the sample at 46:34 is missing? Only when you spend one hour CAREFULLY listening to EVERYTHING again…

A useful way to “prove” if anything is like it should is (in my experience) - “save-as” - just right after opening that session, without having touched anything so far… the project file size should be exact the same size than the one you opened. If the file is a bit smaller most likely something is missing.
Another way to prove this (well there is no 100% prove) is to have lats say an UAD plugin on the Mixbus, a group at the very LAST of the tracks - NOT the main out… The Main out will load at first, then all channels, groups etc… the last track in the mixer will be loaded at last. When that plugin (UADplugs for example likes to disappear) is missing - then you have to better close / reopen the session… Sometimes this can need quite some tries… and even reboots.

Phhh sounds like a nightmare with these kind of projects… :frowning:

Why don’t you freeze/render what you are happy with to commit/protect/unload/make space?

well most processing I do on groups/busses so freezing / render is not an option, but that sample at 46:36, yes - sometimes I just render stuff like that.

Hi,

the plug-ins not loading are theoretically those who need attention and dynamic linking. Does not matter if they are old or not, but how they link to the library (the limitation itself exists since XP, IIRC - it was just difficult to hit it with a Pentium 4 :wink: )

As per the ways of dealing with the issue, GerogeV just linked this post which explains the behaviour pretty well:

Maybe the last part especially gives hints on how to circumvent the problem, for example by reducing the amount of unique plug-ins - which is kind of my workflow and probably the reason why I personally never stomped on this issue (I tend to use the same plugs, for example SSL Channel E on all audio tracks, Pro-G on all drums, Portico on all groups, etc.). I don’t know to which extent this approach is possible for you (Brandy).

I want to base my future purchases on whether they statically link this C library or not. I tried using a software called Dependency Walker, but it didn’t make clear to me which ones did it. Is there a way to find this out?

I didn’t know about that difference. So inside of it there can be multiple DLL files? I indeed noticed Cubase’s stock VST3 plugins are all in one file now you mention it.

I don’t know if it’s possible using WPA or other (perhaps not THAT complex) tools.
Will check with the devs.

Yes, that’s the reason why you usually have a single .vst3 file in place of a mono and a stereo VST2 .dll (just as an example, DMG Audio Compassion comes with a mono, a stereo and a side-chain VST2 version, but only one .vst3 file).