Vst count limit - Steinberg please do something!

Cubase
#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…

#21

I contacted Universal Audio about this last year after a Steinberg employee told me plugin manufacturers need to get onboard. I can copy the reply here if I can find it but in a nutshell they told me that only 1 or 2 had reported the problem and with the amount of programming effort involved plus the fact that they value OSX customers first that it’s unlikely to be ever looked at from their end. Universal audio plugins apparently exhacerbate the problem.

#22

If you say the host software has no responsibility then does this mean this is not a steinberg issue at all?

When you say developers provided an update fixing this. When did that happen and what developers?

Did you read my description of my experience this year with the limit seemingly going away on my system but when I upgrade to 9.0.3 it immediately comes back? Any speculation as to what’s going on?

#23

It didn’t look like an official employee poster at first glance. There needs to be MUCH more said about this problem and awareness. It’s buried and most of the plugin developers are shrugging responsibility. Makes it impossible to mix in the box don’t you agree?

#24

I’m fortunate in that I haven’t experienced this issue at all. I use quite a lot of plugs but presumably not enough unique instances…and no UAD which as you say, seem to be the worse culprits.
I’m mostly mixing in Reaper now as well…Oddly, I can’t find any mention on Reaper forums of this problem.

#25

Mostly mixing on Reaper?! :slight_smile: What do you use cubase for in this case? Also, same point to Last comment by steinberg employee that it’s not the host’s fault. It’d be useful to know if Reaper indeed is or isn’t affected.

#26

Quick test Cubase vs Reaper. Loading 6 plugs per channel - Plugs selected in manufacturer order from my collection so all the same plugs loaded at first.

Cubase failed to load the 53rd unique plugin. Tried a few other plugs and managed to load another 2 but that was it.
Reaper loaded 104 unique plugs and then gave an error that plugin cannot be loaded…tried a few more but all gave the same error until trying to load a waves plug crashed it completely.

So seems the limit is there but is way higher than in Cubase.

#27

Thanks YVan from Steinberg for the valuable info.

Also thank you Grim for the tests, interesting findings. Adding to that, according to Cakewalk, Sonar can handle at least 64 unique plugins. Fabio mentioned before that Cubase can handle a similar amount, so Grim’s number (53-55) makes sense. I suppose the number may vary depending on the actual plugins you use. But Grim’s method is very good, for comparing

Reaper seems to be doing well on this issue. Based on this workaround to increase (a bit) the amount of loadable unique plugins in Cubase:

Those extra features in Cubase are obviously reducing the number. And Reaper surely handles the issue much better, twice the number of plugins!?
Let’s hope Steinberg developers can increase the number of unique loadable plugins within Cubase…

#28

Does Reaper really support more of the same 64-bit plugins compared to Cubase? A certain test I did shows that it’s not better off than Cubase, but it might be wrong.

#29

The next cubase release is likely around the corner. Will we see this addressed?

#30

Ofcourse not, as explained many times, it’s not the daw, but the type of plugin and in what combination used.

#31

Anyone able to comment on how 9.5 performs with the limit?

#32

Did some tests yesterday comparing to C9.

Loaded one by one just using the next in the list, the limit was at 104 indivudual plugins. Then I tested my all time favourite UAD plugins exclusively, here the limit is reached with just 31 different plugins (C9 gave me 42). Probably I could get some more by disabling hub, video etc., seems there are some more components in 9.5 that are pre-filling those ‘slots’.

So still it seems to depend on how plugins are communicating with the rest of the system (sorry, I’m not an IT guy and have never really understood what exactly is going on, so forgive my ignorance and lack of correct technical terms here). In a usual session with mixed native & dsp plugins I guess I’d come up to 60/70 indivudal plugins. Hmmmmm.