VST plugin loading limitation on Windows

Audio Plugin Hosts and other audio software applications discussion
RELATED
PRODUCTS

Post

It's definitely something to do with Win10.

I have been using Cubase 8.5 on W7 and I could load as many plugins as I wanted.

The problem started when I upgraded to W10.

Post

"This issue affects all host applications written in the C++ programming language, except those who allow loading plug-ins into separate processes (which isn’t always feasible for low-latency real-time audio applications)."
I am curious how Bitwig, Reaper, and others are not having this problem.

Steinberg maybe will finally refactor this terrible spaghetti of Cubase sold as premium quality.

Post

You can only load 64 plugins with the latest windows 10 in the worst case (statically linked and built with visual studio 2017).

https://forum.juce.com/t/important-brea ... ault/25276

Post

Zookes wrote:"This issue affects all host applications written in the C++ programming language, except those who allow loading plug-ins into separate processes (which isn’t always feasible for low-latency real-time audio applications)."
I am curious how Bitwig, Reaper, and others are not having this problem.
Youve answered it yourself with the quoted text about separate processes
Amazon: why not use an alternative

Post

if we only had a freeze function in software where by the midi file would be converted to wav or ogg thus freeing up space for more plugins.
Synapse Audio Dune 3 I'm in love

Post

Boy am I glad still being on win7 after reading this thread cause I'm a total plugin maniac :D
"People are stupid" Gegard Mousasi.

Post

Zookes wrote: I am curious how Bitwig, Reaper, and others are not having this problem.
This post is intended to share my recent experiences with the FLS limitation issue, and to provide some more detailed information as well as a work-around strategy. It is based on using REAPER as DAW but also users of other Windows DAW systems might profit from it to get to improve their situation.

I apologize in advance for the considerable length of this post.

1) CONTEXT

Recently I changed from FL Studio to REAPER because with FL Studio I had been suffering from CPU capacity issues as well as from plugin loading problems, both for larger projects with many plugins. After I had concluded that REAPER offers a much better multi-core approach I spent some time to rebuild my mastering template and then I started a few weeks ago to load a big project I had been working on in FL Studio previously. Everything went well until the last 3 tracks, when I suddenly got an error message every time I wanted to load a new plugin... It seemed to be the return of the 4GB RAM limit issues I experienced a few years before with 32-bit plugins, but I was using the 64-bit version of REAPER and almost all the plugins I was using are 64-bit as well. What was even more strange was that I could load without problems multiple copies of any plugins that were already present in my project, but trying to load any new plugin resulted in failure messages. What was wrong??? :help:

I searched the web for experiences of other REAPER users but initially I did not find anything that could explain it. Then I found a 2 years old thread on the Steinberg forum and while reading I started to recognize exactly the same issue as I was experiencing:

https://www.steinberg.net/forums/viewto ... 26&t=95005

Searching further with the right keywords, I finally found this and several other threads that helped me to fully understand the issue:

https://www.steinberg.net/forums/viewto ... 0&t=123768
https://uadforum.com/support-troublesho ... -only.html

(I will not re-explain the FLS limitation issue here, so instead I suggest reading all previous threads that should give sufficient information)

My main conclusion is that it will probably take a (very) long time for this issue to remain present:

- some plugin developers might change their strategy but there will be for sure many FLS consuming plugins remaining
- some DAW suppliers might help us (I will give some ideas at the end) but I am not sure if they will add this to their strategy
- only Microsoft could fully take away the FLS limit but apparently they have their reasons not to do so

As a result, the only way to continue using Windows systems for large-scale projects with many different plugins is to live with this issue and to try finding work-arounds, which is the main subject of this post.

To finalize this context section, some information about my system configuration:

- Windows 10 64-bit system with i7-6950X 10-core/20-thread CPU and 64GB RAM (please note that I found exactly the same FLS limitation issue on a Windows 7 system)
- Main DAWs FL Studio and REAPER (I found the FLS issue on both)
- More than 1000 different plugins (UAD, Waves, Plugin Alliance, PSP, Melda, Fabfilter, Blue Cat, UVI, D16, Sonnox, Arturia, Voxengo, Tone2, Vengeance, ...)

2) MEASUREMENT AND RESULTS

One of the main problems is that the FLS limit is initially totally invisible. We are all used to focus on CPU capacity and RAM usage to avoid issues, but the FLS usage is only shown when it is too late: when no more plugins can be loaded! Therefore the first requirement for living with the FLS limitation is to know at any time how many FLS slots are left.

Fortunately REAPER offers a way to obtain this information. The debug console (access through the actions menu) has a special command "tls_avail" which responds with both the number of remaining TLS and FLS slots. In order not to type "tls_avail" every time I made a special AutoIt script running in the background, which will automatically send this command to the debug window once it opens, and close it again afterwards. All I have to do is pressing the F12 key (that I configured to open the debug console), then the debug window opens and shows automatically (via the script) the FLS status, and when I press F12 a second time the window will close again. This makes a world of difference, since it allows to check for any of my plugins their exact FLS usage, and I can see at any time how many FLS slots there are left when building a project.

Further to the above threads that were already giving some information about the FLS usage of certain plugins, I would like to share some of the conclusions after checking the number of FLS slots for each of my plugins:

- (specific to REAPER) The initial number of slots showing up without any plugin loaded is 116 for REAPER-32 and 119 for REAPER-64. However when the first plugin is loaded, 5 additional slots are used, so in reality these figures are 111 for REAPER-32 and 114 for REAPER-64.

- (specific to REAPER) At the moment a project is saved for the first time, 6 additional slots are used... and even after the menu option "Save as..." is selected without actually saving, the FLS counter is reduced with 6 slots!!

- Most plugins are consuming just one FLS slot, but for some suppliers they will need two slots: UAD, Fabfilter, Cableguys, 2CAudio, Unfiltered Audio, PSP (recent plugins with iLok), D16 (recent plugins).

- Some suppliers need a larger amount of FLS slots for their first plugin: 1st Waves plugin 6 slots (but afterwards most Waves plugins use no slots at all), 1st Melda plugin 6 slots, 1st UAD plugin 5 slots, 1st Vengeance plugin 3 slots.

- High numbers of slots are needed for the Arturia plugins (as already mentioned in other articles). Analog Lab 3 uses 47 slots (!!), 10 slots are needed for Minifilter, and 4 slots for most of the other Arturia plugins.

- Several common VSTi plugins use 2 slots each: Sylenth 1, Rapid, ANA2, Kick 2, Thorn, ...

- Finally one positive exception: 32-bit plugins!! Even if some older 32-bit plugins are using large amounts of FLS slots (e.g. Alionoctis 21 slots, Virtua Drum 20, Analog Warfare 12), when using a 64-bit DAW like REAPER or FL Studio that allows to bridge 32-bit plugins, these plugins will not use any FLS slots of the main DAW process (I will come back on this in the next section). So whereas my strategy up to now was to avoid using 32-bit plugins as much as possible, suddenly they have become much more attractive! :D :D

In my case there is one other factor that caused me to hit the FLS limit much faster than most others. Within my setup I am using several Novation hardware devices to access each of my plugins with Automap software (using dedicated Automap profiles for each of my plugins). As a result, all my plugins are accessed through special Automap DLL files which then communicate with the corresponding plugin. But... I found that these Automap DLL files each need one additional FLS slot!! So in this situation, almost all plugins need at least 2 FLS slots... which makes the issue clearly worse (please note that all the FLS slot numbers I have given here above are the numbers without using Automap).

3) WORK-AROUND STRATEGY

After understanding the issue in detail, it seemed like I had to choose between several options that would either limit my workflow (using less plugins / bouncing more tracks / taking off the Automap feature) or challenge my system resources in a different way (like bridging all plugins - but when bridging all plugins, not only each different plugin will have its own process, but also each new instance os plugins already used, which would result in a very resource-demanding situation, especially for real-time audio).

But after considering in more detail, I found that actually the various ways in which plugins can be configured within REAPER allow using than one process to run plugins, without the need of bridging every single plugin and thereby creating hundreds of additional processes. REAPER enables the user to select one of several process options for each individual plugin:
- either running as a part of the main DAW process,
- or in a separate second process, intended to run buggy plugins without crashing the main process,
- or in a separate third process, reserved for 32-bit plugins only,
- or in a dedicated process (one process per plugin instance, an option which can be selected for both 64-bit and 32-bit plugins).

As a result, 3 separate processes are available to run plugins, thereby offering 3 times the number of FLS slots, and in addition dedicated processes can be used when more slots are needed! After making some calculations on the average usage of various plugin types in my projects, I changed my REAPER configuration as follows:

- all 64-bit VST plugins are set to run in the main process, except UAD/Waves/Fabfilter/Arturia/Mux/Bidule
- all 64-bit VSTi plugins, as well as all Waves VST and Fabfilter VST, are set to run in the second (separate) process (normally I use less different VSTi than VST plugins, therefore I added all Waves and FabFilter VST plugins to the second process for a better balance)
- all 32-bit VST and VSTi plugins, as well as all UAD plugins, are set to run in the third (32-bit) process (for all UAD I now only use their 32-bit version instead of the 64-bit version, since I will not use many 32-bit only plugins and as a result the remaining slots in the 32-bit process become available for my full UAD collection)
- all VST/VSTi plugins with high individual FLS usage (e.g. Arturia) and all plugin racks (e.g. Mux, Bidule - which can contain other plugins and therefore may have high FLS counts) are set to run as dedicated process (in practice there will be only a few of these per project, which does not cause any issues for the total number of Windows processes)
- finally, I have added for each of my plugins an additional JBridge version into the REAPER FX Browser, so that in case I would be out of FLS slots in one of the 3 processes (in case of a very large project) I can always add a bridged version of any plugin (running in its own Windows process without FLS limitation).

In this way I can use as much plugins as I need, I do not have to bounce any tracks, I can keep the Automap feature (I have just taken off the Automap option for certain plugins) and my CPU cores only see a few additional Windows processes. To give an idea of the improvement: for the project that initially caused me the FLS shortage issue (due to a FLS count at zero), I now see a FLS count of 72 for the main process (i.e. almost two third remaining) and for the two other processes I still have a lot of FLS capacity left as well (without using any bridging into separate processes).

4) SUGGESTIONS FOR DAW SUPPLIERS

I would like to end with two suggestions for the DAW suppliers:

- offering a direct view on the number of the remaining FLS count, ideally for the various processes within the DAW environment (e.g. for REAPER I would appreciate to be able to see the exact FLS count also for two other processes - separate and 32-bit). It would be great to have next to the CPU and RAM indicators - as we can find on every DAW - a figure showing the remaining FLS slots per plugin process!

- increasing the number of Windows processes to run plugins (why not offering 5 or 10 additional processes bringing each their additional FLS capacity, with either manual or automatic configuration per plugin - like a CPU can have 10 cores, a DAW could have 10 Windows processes to run plugins in and then the FLS issue would be totally gone)...
Last edited by Lucas-Paris on Fri Mar 23, 2018 2:19 pm, edited 1 time in total.

Post

shroom81 wrote:Boy am I glad still being on win7 after reading this thread cause I'm a total plugin maniac :D
As mentioned above, the WORST case is being limited to 64 plugins. So, in general, you should be able to load more. The question is, do you really, really need more than 80 plugins loaded at a time? I doubt it TBH. :P Prolly the CPU will be the limiting factor already here.

It almost made me want to create poll to determine if anyone ever ran into that limit. And, as i have so much fun guessing, i also doubt that more than a handful ever really did.

Post

chk071 wrote: As mentioned above, the WORST case is being limited to 64 plugins. So, in general, you should be able to load more. The question is, do you really, really need more than 80 plugins loaded at a time? I doubt it TBH. :P Prolly the CPU will be the limiting factor already here.

It almost made me want to create poll to determine if anyone ever ran into that limit. And, as i have so much fun guessing, i also doubt that more than a handful ever really did.
My limit used to be the CPU capacity when I was using FL Studio on a previous 6-core CPU PC, but with the excellent REAPER multi-core performance and a 10-core processor that has now definitely changed. The project I described in my previous post is based on a Mastering template with 32 different plugins (about half for monitoring and visualization purposes) and once I add 30-40 tracks with a selection of different VSTi plugins and several FX per track, the 64 different plugins count is very close and the 80 limit not very far... to give you an idea, with about 150 plugins for 35 tracks I see a REAPER RT CPU capacity of less than 5% and my overal system (Windows) CPU capacity is between 15 and 20%. So the main limit (without the work-around as I described) is clearly the FLS count.

Post

Such a shame. I'm going to cry.

There, I'm crying. :cry:

But wait... I don't use W10! oh.... :dog: :party: :tu: :clap: :pray: :love: :P :lol: :hihi:
It is no measure of health to be well adjusted to a profoundly sick society. - Jiddu Krishnamurti

Post

DuX wrote: But wait... I don't use W10! oh.... :dog: :party: :tu: :clap: :pray: :love: :P :lol: :hihi:
Don't get it wrong. The TLS and FLS limits exist just the same for example on Windows 7. I tried reaching the limit on my system (Windows 7 64 bit and Reaper 5 64 bit) but it looks like I don't have enough different plugin dlls installed at the moment...

Post

Xenakios wrote:The TLS and FLS limits exist just the same for example on Windows 7
I confirm. I did the same tests on Windows 7 (with all regular updates from MS) as on Windows 10, using both REAPER and FL Studio. The FLS limit is exactly the same on Windows 7 as on Windows 10 and REAPER 64-bit shows on W7 the same number of 119 available FLS slots without any plugins loaded. I also tried to load an older large project of a few years back that I made in FL Studio, and I could not load it anymore without 'unable to load' error messages for a part of the plugins, both on W7 and W10. Previously I already saw similar error messages in FL Studio but I did not know why - now I know the reason: not enough FLS slots.

Post

FYI - All ToneBoosters plugins have been updated some time ago to dynamically link against runtime libraries to overcome TLS and FLS limits 8)

Post

djeroen wrote:FYI - All ToneBoosters plugins have been updated some time ago to dynamically link against runtime libraries to overcome TLS and FLS limits 8)
The ToneBoosters plugins I tested are part of the Bustools series v3.1.8 (dated August 2017) and they are each using 2 FLS slots.

Post

Lucas-Paris wrote:
djeroen wrote:FYI - All ToneBoosters plugins have been updated some time ago to dynamically link against runtime libraries to overcome TLS and FLS limits 8)
The ToneBoosters plugins I tested are part of the Bustools series v3.1.8 (dated August 2017) and they are each using 2 FLS slots.
The relevant update was introduced in v3.2.0 (January 2018). This means that you have been testing old versions that (back then) indeed used static linking.

Post Reply

Return to “Hosts & Applications (Sequencers, DAWs, Audio Editors, etc.)”