KVR Audio

LawrenceF · Post by **LawrenceF** » Tue Sep 10, 2019 3:42 pm

In Studio One the first scan is a full scan and if you have a kazillion plugins it will take awhile. It (like all others I would suppose) stores all of that info.

After that (as chk01 suggested) starup scans are just "quick checks", and will add any new plugins. I keep "Scan at Startup" turned off because you can click Update Plug-Ins at any time to scan in new plugins.

stash98 · Post by **stash98** » Wed Sep 11, 2019 1:54 pm

LawrenceF wrote: ↑Tue Sep 10, 2019 3:42 pm In Studio One the first scan is a full scan and if you have a kazillion plugins it will take awhile. It (like all others I would suppose) stores all of that info.

After that (as chk01 suggested) starup scans are just "quick checks", and will add any new plugins. I keep "Scan at Startup" turned off because you can click Update Plug-Ins at any time to scan in new plugins.

Ok nice. I will turn that off. It’s probably the problem.

Forgotten · Post by **Forgotten** » Wed Sep 11, 2019 1:57 pm

stash98 wrote: ↑Wed Sep 11, 2019 1:54 pm
LawrenceF wrote: ↑Tue Sep 10, 2019 3:42 pm In Studio One the first scan is a full scan and if you have a kazillion plugins it will take awhile. It (like all others I would suppose) stores all of that info.

After that (as chk01 suggested) starup scans are just "quick checks", and will add any new plugins. I keep "Scan at Startup" turned off because you can click Update Plug-Ins at any time to scan in new plugins.
Ok nice. I will turn that off. It’s probably the problem.

If that doesn’t work, it could be a corrupted cache that is causing a full rescan each time you start it. Not sure if the process to delete the cache, so if you have the issue still, maybe someone can provide guidance to do that.

v1o · Post by **v1o** » Wed Sep 11, 2019 2:23 pm

Xenakios wrote: ↑Fri Aug 30, 2019 4:14 pm It looks for new or modified plugin binary files. When it finds one, it loads the plugin and gathers information like plugin and developer name, whether the plugin is an instrument or an effect and so on. Because it needs to load the plugin to get that more detailed info, the scanning process may take a long time because plugins can be slow to load due to copy protection, loading audio files etc...Correctly working hosts should cache that information and avoid rescanning the plugins.

Like was mentioned above, just going through all the files in the plugin folders can itself become a slow thing if there's also a ton of audio files, presets or something like that in those folders. (Operating systems may have fast functions for searching only files of a certain type etc, but not all hosts may be using those functions.)

You would think they would put that information in some sort of separate XML file attached to the VST DLL. To speed up the scanning process. The current way scanning is done can lead to crashes and all sorts of strange behaviour.

Xenakios · Post by **Xenakios** » Wed Sep 11, 2019 6:20 pm

v1o wrote: ↑Wed Sep 11, 2019 2:23 pm You would think they would put that information in some sort of separate XML file attached to the VST DLL.

Well, it's too late for that now. There are already thousands of VST2 plugins around that don't have that.

Forgotten · Post by **Forgotten** » Wed Sep 11, 2019 6:44 pm

Xenakios wrote: ↑Wed Sep 11, 2019 6:20 pm
v1o wrote: ↑Wed Sep 11, 2019 2:23 pm You would think they would put that information in some sort of separate XML file attached to the VST DLL.
Well, it's too late for that now. There are already thousands of VST2 plugins around that don't have that.

Yep. It would involve changing or creating a new standard, along with all the baggage that usually entails.

THE INTRANCER · Post by **THE INTRANCER** » Wed Sep 11, 2019 8:46 pm

The problem with turning off scanning in Studio One for example is that, whenever you added plugins, you often forget that you've turned off scanning and thus you wonder why the plugins don't show up whenever you go look for them. There should probably at least be a temporary flag to remind you that any new ones have been added even with plugin scanning off.

jabe · Post by **jabe** » Thu Sep 12, 2019 2:26 am

Obineg+ wrote: ↑Sun Sep 08, 2019 9:52 pm what does scanning mean?

well, scanning means loading:

No.

Obineg+ · Post by **Obineg+** » Sat Sep 14, 2019 12:00 am

v1o wrote: ↑Wed Sep 11, 2019 2:23 pm You would think they would put that information in some sort of separate XML file attached to the VST DLL.

a seperate file / meta data could still hold wrong info. only actually reading the file will tell the truth.

v1o · Post by **v1o** » Sat Sep 14, 2019 3:55 am

Obineg+ wrote: ↑Sat Sep 14, 2019 12:00 am
v1o wrote: ↑Wed Sep 11, 2019 2:23 pm You would think they would put that information in some sort of separate XML file attached to the VST DLL.
a seperate file / meta data could still hold wrong info. only actually reading the file will tell the truth.

Why would a developer include wrong information with their VST?

digitalboytn · Post by **digitalboytn** » Sat Sep 14, 2019 4:51 am

At KVR "scanning plugins" has a whole different meaning...

Around these parts,it's when someone is perusing the plugin offerings on the web and then,quite often handing over money to use those plugins,so that they can feel a great sense of satisfaction and see a small decline in their GAS levels for a minute or two

Obineg+ · Post by **Obineg+** » Sat Sep 14, 2019 9:11 pm

Why would a developer include wrong information with their VST?

why should anyone copy text and info by hand which could as well read out from the document itself?

it is really easy to introduce typo´s e.g. with the unique ID or even the name, or accidentially claim an instrument would have 2 inputs.

or you update your plug-in from version 2.0.1 to 2.0.2, change something in the VST realm (for example fix a bug) but forget to change the filename, the ID, or the description xml.

validation is a process which should make SURE that THIS file works with THIS host or fullfill specs or whatever. errors can here only be avoided when you scan stuff in question live, not supply meta data.

scanning often checks for double files and stuff like that. which xml belongs to which file if there is a double?

Decibelianix · Post by **Decibelianix** » Sun Sep 29, 2019 10:58 am

In Cubase and Windows, a nice trick to speed-up the initial scanning process is to add to the whitelist in Windows Defender both the VST Plugin folder and the Cubase .exe file.

After doing this, I can start now Cubase in seconds, when before it was taking at least 2 minutes - all because Windows Defender was scanning every single VST called up by Cubase on start up.

This might work for other DAWs, it´s worth trying!

chk071 · Post by **chk071** » Sun Sep 29, 2019 11:17 am

JulsnJVM wrote: ↑Sun Sep 29, 2019 10:58 am In Cubase and Windows, a nice trick to speed-up the initial scanning process is to add to the whitelist in Windows Defender both the VST Plugin folder and the Cubase .exe file.

After doing this, I can start now Cubase in seconds, when before it was taking at least 2 minutes - all because Windows Defender was scanning every single VST called up by Cubase on start up.

Lol.

I use Defender as well, but... it's a really slow antivirus. Slower than any other i tried. It takes 5 or 6 times as long to scan files. I really hope Microsoft will improve the speed at some point.

Decibelianix · Post by **Decibelianix** » Sun Sep 29, 2019 11:32 am

chk071 wrote: ↑Sun Sep 29, 2019 11:17 am Lol. I use Defender as well, but... it's a really slow antivirus. Slower than any other i tried. It takes 5 or 6 times as long to scan files. I really hope Microsoft will improve the speed at some point.

I´m OK with Defender, it keeps my DAW protected without having to bother about it. That is, as long as it doesn´t interfere with DAW work. I mean, why does it have to re-scan the VST files on every single startup? lol

The whitelist trick solved that for me, hope it helps others!

What does scanning VST plugins actually mean?