I’m sure it is on the list already: please develop a way to bypass the dll limit, which seems to be an intentional Windows design.
Problem: after a certain point (depending on system configuration) it’s not possible to use another unique plugin. There’s a number of (plugin-)dlls that can be handled. Once it’s exceeded, a plugin that is not yet used in the project will refuse to load.
Current workaround: use a plugin that’s already used in that project instead (dll processes are shared with all other instances of that specfic plugin) - here your cpu power is the only limit.
Annoying - happened to me for the first time recently: a project that has worked while mixing had plugins missing on opening another day (without notice). Project sounds different and you might not even realize in the first place, i.e. imagine automated sends that just spit a few words into an FX channel for a delay which is suddenly missing. Spend two days troubleshooting an album mix these days, had to cancel a studio session while musicians were around for a joint finetuning session.
It’s not Cubase and not Cubase only (happens as well in other DAWs on Windows) but Cubase needs a way to bypass that limitation.
Until recently it didn’t matter much to me. When that limit was reached it was, well, reached. Irritating but no reason to believe any esoteric xyz-compressor might make a big difference (at an advanced state of a mix where those issues tend to arise) compared to a channelstrip comp or another instance of one used already. No showstopper. The above described behaviour to not load plugins when opening the session again later - though it was possible to insert them while working on the project - was new to me. Re-checking in 8.5 showed the same behaviour. C9 on Windows 7 here, in the other threads on the issue it seems Windows 10 users face the same problem.
My system can handle 43 unique UAD plugins untill it refuses to load more. Pure native plugins go up to +100 (whatever-I-don’t-understand defines the limit). In my real world scenario, using plenty UADs, that’s an average of 60/70 unique plugins. Way enough to do a great mix.
If I disable one or more tracks with plugins on it, it’s possible to insert further unique plugins.On re-enabling the tracks, some or all plugins on the re-enabled tracks don’t show up (!) - the insert field(s) come up empty without a warning.
Possibly that’s the way I was able to create the mess described above (‘annoying’-section). Thought I let you Cubase fellows know, knowing about the weaknesses is a first aid. Simply removing the limits would be the real aid. If that requires deep level changes to the audio engine or whatever and therefore is not-so-easy to do I’d take a warning message for the time between
Yes your exactly right. Same on my system. Support has told me its on the agenda. Why Cubase 9 would have been released with this problem untouched is amazing to me
Basically it is some compiler settings that has to change, but that would have to be tested extensively making sure nothing else breaks. Wavelab does not have this problem, and they are fully aware how to do it. My guess is that there was no time to test with the Cubase 9 release being the main focus.
I don’t think it’s a real factor in Wavelab. Think Wavelab has just the plugins for the currently playing file active, I see no real world situation where I could manage to break the limits there. The maximum number of plugins to be applied to a single file is in the montage. 10 plugins per clip, 10 per track, 10 per montage output, 10 in the master section. Ok, of course the montage can have multiple tracks, so it’s definately possible to exceed limits but that’s an extreme scenario which is unlikely at least in my world
But just to know I stacked plugins into plenty montage tracks - there’s also a limit obviously. Somewhere between 60 - 70 there’s an error message. Hey, there’s a message!
Well that is what I got from the discussion on the developer forum.
Studio one has been updated, and wavelab never had the problem.
Of cause there are other factors, UAD and Waves seem to have their own problem with OpenGL that are unrelated to this problem, and resulting in empty GUI’s.
Anyway I think this will be addressed in an upcoming update.
Here here… it’s such an important issue to rectify. You guys need to contact all of your plugin vendors though. Uad say it’s not currently priority as only 5 users have reported it. I can’t believe that. I was pretty emphatic about it to support but their telling me only people power will get it shifted up the priority ladder as it’s not a trivial problem.
Now when they increased insert fx limit in 9.5 more people will have this problem like us. Anyway I’m coming from Reaper (previously FL Studio + Reason)…trust my I use a loot of plugins like 200. And NEVER had this problem in any other daw. The only problem was low ASIO buffer that had to be increased or something had to be bounced to wav when ASIO buffer was full. But there was no problem loading additional unique VSTs!!!
i7 hexa core (12 threads), 24 GB RAM, RME RayDat PCI Express (ASIO buffer can go up to 4096)
So I made this awesome project in Cubase and now it looks like I can sell it and spend additional 10 hours with manual preparation of tracks in Reaper with the same settings. It would be cool if there would be some open xml project daw standard, so when Steinberg messes up again, I can take my insert fx with their settings and migrate without the need to save each preset manually and export midi like that.
EDIT: Also in Reaper you get this nice performance chart and see exactly which channel or VST takes how much CPU and make your decisions based on that without running like a crazy whore through 60 channels bypassing on & off.
Someone on the forum (‘Grim’ I think) did a quick test as he had Reaper and Cubase 9 on his system and reported back on another thread that Repear on PC does suffer a limit but the limit seems to be much higher.
In case the limit is reached near the completion of a project, removing some Cubase components might be just enough to get there. A quote from a previous post:
For the time being, those who have the problem can lower the amount of loaded dlls by moving some of the components out of the folder C:\Program Files\Steinberg\Cubase 9\Components. Of course, this applies only to the dlls which are not needed during use (eucon if you don’t use such controllers, video files if you don’t need video support, hubservice, etc - make sure to not remove any core component like Baios, the exception dumper, mediaservice, SamplerTack, stepdesigner and the VST files). This will allow for more plug-ins… not much more, but could help some of you.
euconadapter (support for Euphonix / AVID controllers)
hubservice (Steinberg Hub, without this, you will only see the Project Assistant, the Hub on the left will be missing)
omffilter (you will be unable to import OMF files)
video (all files, of course all video features will be missing)
vstconnect
Being the limitation on Windows and also requiring intervention from 3rd-party VST developer to fully resolve it, it indeed persists.
The only work-around is to use jBridge.
Steinberg engineers are already working on linking dynamically to libraries, which will allow to load some more plug-ins. This is the only action we can take, but it won’t fully resolve the problem, if VST devs don’t switch to dynamic linking too: it’ll only push the limit a bit further.
I’m closing this discussion, as there are several threads on the topic already and ‘Remove dll limit on Windows’ is a request Steinberg cannot fulfill.
