New windows 10 update performance improvement?

[cqd]

Hi,

Just wondering if a people are using the latest Windows 10 19h1 build yet, and should we expect a performance improvement in Pro tools?..

https://ask.audio/articles/this-wind...ns-in-your-daw

[YYR123]

Texas reporting here

No, not using the update

[junkgear]

Originally Posted by cqd

Hi,

Just wondering if a people are using the latest Windows 10 19h1 build yet, and should we expect a performance improvement in Pro tools?..

https://ask.audio/articles/this-wind...ns-in-your-daw

You won't see a performance increase from the FLS update in Windows, but it does allow more plug-ins to run. The number of plug-ins isn't a fixed number though. The update deals with how the plug-in was built (software wise) and varies per plug-in.

[jjnssn]

Originally Posted by junkgear

You won't see a performance increase from the FLS update in Windows, but it does allow more plug-ins to run. The number of plug-ins isn't a fixed number though. The update deals with how the plug-in was built (software wise) and varies per plug-in.

Curious do you know if the FLS update resolves the issue when a guy has hundreds of plugins and pro tools is building the AAX plugin data file at start where a guy gets an error and then has to continue to restarting pro tools until all plugins gets scanned properly with no errors?


Sent from my iPhone using Tapatalk Pro

[junkgear]

Originally Posted by jjnssn

Curious do you know if the FLS update resolves the issue when a guy has hundreds of plugins and pro tools is building the AAX plugin data file at start where a guy gets an error and then has to continue to restarting pro tools until all plugins gets scanned properly with no errors?

I don't know enough about what PT is actually doing during the scan, but in theory, it could help this situation. The FLS slots are used when the plug-in is loaded, so if PT is loading all of your plug-ins during the scan and you hit the limit, I would imagine there would be errors.

Will be interesting to see what happens.

[jjnssn]

Originally Posted by junkgear

I don't know enough about what PT is actually doing during the scan, but in theory, it could help this situation. The FLS slots are used when the plug-in is loaded, so if PT is loading all of your plug-ins during the scan and you hit the limit, I would imagine there would be errors.



Will be interesting to see what happens.

Thanks for clarifying. I am interested for this reason.


Sent from my iPhone using Tapatalk Pro

[jjnssn]

I updated to the 1903 Preview which is supposed to be released here in May out of morbid curiosity to determine if this update would resolve the issue of errors when scanning many plugins at startup after deleting the AAE plugin database file.

Deleted my AAE plugin database and started proTools to forces rescan. PTs started and finished the rescan without the typical errors and the need to restart ProTools.

Maybe biased. Gut feel sessions load and close faster.

However, ProTools hung when closing, however eventually closed. So YMMV.

Sent from my iPhone using Tapatalk Pro

[DonaldM]

If I understand the article correctly, the number of plugins you can run might not be limited anymore, but that won't effect CPU limits. You can still only run as many plugins as CPU will allow. Is that correct?



Every once in a while I get the error window telling me I've got too many plugins running in PT. I assume its because of the issue that Windows is now fixing. But, how does that help with CPU limits?



I'm not a computer software engineer, so a lot of this deep under the hood stuff can get confusing for me.

[junkgear]

Originally Posted by DonaldM

If I understand the article correctly, the number of plugins you can run might not be limited anymore, but that won't effect CPU limits. You can still only run as many plugins as CPU will allow. Is that correct?



Every once in a while I get the error window telling me I've got too many plugins running in PT. I assume its because of the issue that Windows is now fixing. But, how does that help with CPU limits?



I'm not a computer software engineer, so a lot of this deep under the hood stuff can get confusing for me.

You are correct in the fact that this update does nothing for the CPU limits. Your computer, and PT, will still be limited by what your CPU can do.

I'll try to explain what this fix does....
When a plug-in is built, it links to certain common system dlls. There are two ways of referencing these system dlls from the plug-in; dynamically and statically.

Now let's say we have two plug-ins; PlugA.aax and PlugB.aax and both of these plug-ins use a file called msvcrt.dll.

If both PlugA and PlugB were built where they dynamically link to the dll, and both plug-ins were loaded in a session, then only one copy of msvcrt.dll would be loaded and only one FLS slot would be used up.

Now if either PlugA or PlugB were built where they statically link to the dll, and both plug-ins were loaded in a session, then two copies of msvcrt.dll would be loaded and two FLS slots would be used.

Now, a single plug-in uses a lot of linked dlls and probably only a handful of them are shared, plus there are reasons for statically linking, so just switching to dynamic wouldn't alone clear this up.

The increased FLS limit allows for more instances of a single instance of a dll to be loaded, which allows more plug-ins to be loaded.

Hope that helps a bit.

[DonaldM]

Originally Posted by junkgear

You are correct in the fact that this update does nothing for the CPU limits. Your computer, and PT, will still be limited by what your CPU can do.

I'll try to explain what this fix does....
When a plug-in is built, it links to certain common system dlls. There are two ways of referencing these system dlls from the plug-in; dynamically and statically.

Now let's say we have two plug-ins; PlugA.aax and PlugB.aax and both of these plug-ins use a file called msvcrt.dll.

If both PlugA and PlugB were built where they dynamically link to the dll, and both plug-ins were loaded in a session, then only one copy of msvcrt.dll would be loaded and only one FLS slot would be used up.

Now if either PlugA or PlugB were built where they statically link to the dll, and both plug-ins were loaded in a session, then two copies of msvcrt.dll would be loaded and two FLS slots would be used.

Now, a single plug-in uses a lot of linked dlls and probably only a handful of them are shared, plus there are reasons for statically linking, so just switching to dynamic wouldn't alone clear this up.

The increased FLS limit allows for more instances of a single instance of a dll to be loaded, which allows more plug-ins to be loaded.

Hope that helps a bit.

That makes it very understandable, thank you! For me, right now, I need to upgrade to more powerful CPU. The number of plugins I can have isn't that big of an issue for me because I seldom have huge sessions to work on. Its CPU limits where I usually run into issues. Thankfully we have track freeze and commit, which help things a lot in that regard, but still, it'd be nice to have more power. Especially since so many of the plugins these days seem to use more CPU than before.