Vst count limit - Steinberg please do something!

Cubase
#1

I am sure for some of us on Cubase there is still BIG problem with ocassionaly missing plugins. I read on other forum there is a way to program DAW.
A man from Cakewalk wrote about this issue:

Its a really bad idea to statically link to the C Runtime library. Not only does it bloat the memory space with redundant copies of the runtime libraries it can also prevent efficient use of memory by circumventing caching. Additionally it prevents Microsoft from updating the runtime via service packs. i.e. if there is a bug or security flaw in the C runtimes it can’t be fixed in the future unless the plugin or executable is built with the new runtimes.

Cakewalk has always dynamically linked to the runtimes (for SONAR as well as all our plugins) and we keep up to date with the latest compiler technology. This is why you always see the msvcrt installer included as part of the SONAR installer. While this has had its share of problems its a far better solution than vendors statically linking this in.

BTW the limit due to this is not as extreme as it may seem. In SONAR you would have to have at least about 64 unique plugins that statically linked before you saw a problem, so pretty unlikely I would think. Also multiple instances of the same plugin do not count since the dll is only loaded once. We routinely see hundreds of plugins used in projects and most people tend to use similar plugins like eq’s and compressors on tracks rather than different ones per track. In all the years that SONAR has been around I’ve never heard of a complaint that plugins don’t load so it seems like a pretty small corner case not worth worrying about.

Steinberg do something like others did, your product cares PRO in its name, that s not pro for me!

#2

I’ve used more than 64 plugins…but I use jbridge,that uses a separate thread than cubase,when I first tested my studio i7 I loaded 1000 plugs…20% CPU

#3

1000 Different Plugins?

#4

Did you read the thread you took this quote from? He’s basically saying that it’s up to the plugin developers to not statically link to the C runtime library. That’s the main source of the issue.

#5

Do you bridge them as 64bit plug ins to 64 bit DAW? I know it is possible to bridge them that way but isnt it windows limit of around 70 different dll threads?

#6

Asking Steinberg support on this a year ago to get an estimate of limitation load count - I asked:

What is a large enough project with plugins to get problems?
You could mention if it’s 50, 100, 500 or 1000 plugins.

They said:
The limitation is a Windows issue, its for Microsoft to confirm the number.

I did no accept that and asked again:
They said:
“You don’t need to worry as with you would be required to have a lot more RAM memory to load the necessary amount.”

And I have 16 GB memory.

So that’s how much Steinberg know - no wonder it does not get solved…

#7

It’s the plugin devs that need to use dynamical linking for their plugins, not Steinberg.

#8

Installing Waves stuff there is always these redistributables from Microsoft Visual Studio(2008, 2012, 2015 and whatnot) that are installed too.
So using Waves everybody would be safe?

Looking in ProcessExplorer in a not so large project - 6 effect plugins and 4 synths at the moment - 208 DLL’s are loaded in the process.
Eleven are from Waves.

From the abstract of that post OP got the wrong idea what is the solution. It’s not quite that simple.

And there is actaully at least three levels of linking:
a) static traditional linking into executable file of the code - can be C-runtime or anything else, often a OBJ-file.

b) static linking of import libraries for DLL’s - dll must exist when software start or process does not start.
Shared Runtime C-library MSVCRTxxxx.dll must exist or process does not start if that is used. If statically linked it’s not needed.

c) dynamic linking of DLL’s - you make calls from within software to locate DLL’s and if they exist you can use LoadLibrary and then map each call into that DLL as you need it. Usually done on other stuff than runtime C library. Plugins would be in this category, but most things handled by VST SDK I presume. So all plugins are dynamically linked to daw.
So not sure how all this talk about this C runtime library is valid to the problem.

DLL stands for dynamic link library - so there is some confusion going on over linking methods and DLL’s.

Looking around a bit it seems to be windows 10 only, or?

A bit discussed here:
http://www.kvraudio.com/forum/viewtopic.php?f=7&t=468608&hilit=plugin+limitation+windows

#9

I don’t think it is Window 10 only. I think if redistributables need to be installed, it is a good sign.

#10

Windows 10 comes with it’s own C++ library files, or rather they are now part of the OS.
They are different than the redistributables, as far as I can understand.
That is a good thing, now everyone can start linking dynamically, and drop support for Windows 7 and 8 :slight_smile:

Quick run for cover :slight_smile:

#11

Yes I bridge a 32 and 64 bit into separate folders and cubase uses the 64 bit jbridge,has always worked great …when I did the plug test I made a track with eq,compression and limiter and just duplicated it 999 times with audio…to test CPU

#12

For those interested, Fabio gave some more info on the issue here:
https://www.steinberg.net/forums/viewtopic.php?f=251&t=107253&start=75#p666509

Fabio also answered some questions you may find useful.

Main points:

  • It’s all about the number of unique plugins, a workaround is to use the same plugins many times if you can. Multiple instances of the same plugin do not count since the dll is only loaded once
  • Some plugins use an abnormal amount of available slots (still waiting for someone to identify those problematic plugins)
  • Some VSTs do not release the slots when they are removed from the project - some don’t even after closing the project.
    This last one is new to us and it’s very serious imo. So when you experience something like that DO NOT open another project. Quit Cubase first

Hoping for a quick resolution and in the meantime some more info from Steinberg

#13

What does that solve - dropping 7/8 support?
Especially as it seems Windows 10 are affected by this limitation, or?
A bit unclear still.

I wonder if these new runtime libraries is what I had to add as separate install for Waves at one time - universal binaries?
Some missing entry point starting Waves Central I think it was.
And it works for windows 7 as I have it working.

Looking in ProcessExplorer there were a dozen or two or some c+±named files when a Cubase project was running.

Since Steinberg official support is non-existing these days - maybe it does not matter if Windows 7/8.x are dropped - they will loose customers what ever they do - keeping support or dropping it is all the same. I just know I stay on the Cubase version that support windows 7 and no more money from me. How they backed dropping on Halion 6 is a good sign though, maybe they realize amount of users on windows 7 still.

I think Microsoft dropped Vista of first level of support a year or so ago. Still getting updates as I understand. Dropping to the level as XP was 2014 is next - hard to say when.

Really hope for Steinberg to following path of Microsoft on OS supported.

More than anything I wish for Microsoft to learn how to build a safe OS, so not all these updates changing the machine environment all the time are needed. As to this topic Microsoft seems unaware of how many things for daws with hundreds of plugins working inside one process are affected by various choices they make - plugins limited in load count and many other things on system level. It seems both Avid, Presonus and Steinberg are talking to Microsoft over this.

I think there are some settings on system level - how a machine is used, as a server or workstation and have different approach to how memory is used for disk cache and other things. I think we need other categories for how machine is used - to also include multimedia or not, if being oneline most of the time or similar. To slim OS to necessities needed for the purpose. Now it’s more one size fits all, kind of updates. What i mean is from settings we make on usage - we get updates in optional or important - and can choose not to do them,

#14

This limitation is not new. It has been there since WinXP.

http://www.kvraudio.com/forum/viewtopic.php?f=33&t=491164
Microsoft is looking for audio software engineers and program managers

#15

Dropping support for 7 and 8 was a joke, not going to happen soon.
But it would prevent the plugin/daw manufacturers that are linking dynamically to provide the runtime libraries as they are baked into Win10.
So no more mess with updating them and placing them all over the system, and if unlucky an old version is in the system path, resulting in an error. Has happened to me many times over the years.
Windows 10 is a safe OS, i kind of like the way MS are headed, finally some progress.

#16

Ok, I thought only “run for cover” was a joke.

#17

Hi

we are working on it…
here some technical informations…:ugeek:

We have to face to these issues:

  • each plugin linked with static C-runtime use (independently of how many instance of it):
  • 1 FLS when built under old compiler (Visual 2013),
  • 2 FLS when built with Visual 2015 and newer.

=> Advantage: each plugin has its own memory heap… more stability
=> Disadvantage: FLS is limited to 128 per application, this is quite new due to new compiler and some strategy change in Windows

one solution is to link the plugins with the dynamic c-runtime libraries (c++ too):

  • Advantage: only the first plugin instance with dynamic runtime will use 3 FLS, the next plugin not… no limit anymore…
  • Disadvantage: all these plugins with dynamic runtime share the same Memory heap, this means that a plugin could corrupt an another, and that the memory could be highly fragmented…after a while, with unload and reload plugins… need more investigation…
  • Disadvantage: on Windows 7 in some case (for example Windows not up-to-date), the installation of this Universal dynamic runtime libraries does not work, may be it makes sense to check if you use Windows 7 to install this universal runtime libraries (https://www.microsoft.com/en-us/download/details.aspx?id=48234)

Note:
currently the last VST 3 SDK, provided to plugins developers, uses the Dynamic Runtime by default for its examples…

hope it helps…and not too technical :slight_smile:

#18

The plot thickens with my system. My Plugin limit seemed to disappear around April this year on 9.0.20 but I had been experiencing on 9.0.20 and lots of previous versions of Cubase.
As soon as updated to 9.0.30 the plugin limit immediately came back. I rolled back to 9.0.20 with windows and I’ve been since able to load as many plugin types as I like. Very wierd because this is a REAL issue. All I can presume is that my system is using a Library runtime that was updated by Windows 10 at some time early in 2017 and that when I install the 9.0.30 update there are windows files being deprecated for Steinberg library files. Thats all I can think of.

As far as I was Steinberg were actively working on this but that was a long time ago. It’d be nice to have an update.

#19

Last post by a Steinberg employee in this thread was just three hours before your post :confused:

#20

FYI: The host could not do something for this issue…
Only plugins have to be rebuilt. …
Some plugins use more than 1 or 2 FLS…the first time you instanciate them.(especially plugin loading others libraries ) … We informed the developers and they provided an update fixing this…