The process that bnz suggested worked for me. It was very straight forward and only involved finding VST scanner in the task manager. Thanks for the advice Paul
Maybe something to think about: I think the real solution to this issue is for Steinberg to adjust the VST3 standard to prohibit through the standard that no potentially long running work like authorization checks, network communication etc. must be performed during scanning and all information returned must be statically defined by the plugin. That would clearly put the blame towards the vendors. I don’t see why some vendors have to make the authorization check during scanning while others can do without. Some plugins like guitar rig or waveshell takes ages to scan. Scanning should always be as quick as technically possible.
1 Like
How would the vendors do this?? The authorization check happens because the plugin is opened, period, and at that point, the plugin needs to check for its license.
When Cubase ‘tests’ each VST, it’s literally opening the VST and sends a sample stream to it to make sure it can do its job without any issues. Its not using some secret back door into the plugin that doesn’t cause it to execute. If the plugin processes and passes all the date Cubase sends to it, its marked as good. Unless someone comes up with some new fancy way to test the plugin without opening the executable, its going to check for its license as soon as it opens.
2 Likes
If you know the VST3 SDK for hosts with the IPluginFactory stuff and how the VST3 host scanning works so well, explain the following while your ilok is unplugged:
PS C:\Program Files\Steinberg\Cubase 14\Components> .\vstscanner.exe -p “C:\Program Files\Common Files\VST3\uaudio_ampex_atr-102_tape.vst3”
Or use any other ilok protected UAD plugin. This yields the scanned result even when the iLok dongle is unplugged. When I do the same with a Softube plugin, the authorization window opens.
Magic!
UAD plug-ins all scan successfully without authorization by design. It’s when you open them and try to process audio that improper authorization will prevent them from functioning. When you update your UAD software, every single plugin they make gets installed on your system, in multiple formats. They HAVE to scan successfully so that they can sit in the “unauthorized demo-available” state. So UAD is a poor choice to test in that regard.
Note that other plugins you may test could be cached, so you should check the results of the scanning log to see if the scan was from cache or not.
2 Likes
The point was to show that dongle authorization need not necessarily take place during scanning like Softube or Eventide are doing it. So UAD is exactly the right example. The vstscanner.exe to my knowledge does not access any plugin cache.
No, it’s not.
In this example, the SPL Vitalizer MK2-T plugin is NOT authorized. I can’t run it unless I explicitly begin the trial. However, it scans perfectly well every single time any DAW scans it, because of the way UAD explicitly designed the plugin - this is based on how all plug-ins have individual, built-in trials.
Any time ANY of those UAD2 plug-ins are scanned, they do not perform authorization-on-start verification the same way other plugins do. The absence or presence of your dongle, locally stored license, cloud-based license, or otherwise has no bearing on the startup VST3 scanning process as it regards licensing. As such, the use of those plugins are probably not your best choice for whatever test you’re trying to make. But you do you, of course. You commented on “magic” before, so who knows.
If you examine the contents of the VSTScannerMaster.log file, you’ll see where the plugin is scanned (the 251/469 entry) and if the results of the scan are from VSTScanner already caching the previous scan result. That’s what I meant when I said “you should check the results of the scanning log to see if the scan was from cache or not.” If it was, you may consider moving the file, scanning, and moving it back. Otherwise your tests may not yield intended results of the test.
Good luck with whatever you’re trying to do. I hope it all works out.
Lets agree to disagree. Thats fine for me.
There is another factor to be aware of. There is a flag that plugins can set which effectively disables caching and forces them to be scanned every time. I think Waves plugins may use this because they also have a single plugin binary which provides multiple VST plugins, but the list of available plugins depends on your license, and I think that may be checked on every startup.
3 Likes
Ah true. Those cases where the metadata returned depends on the authorization are not as easy to deal with.
So, just so I understand how this manifests itself, are you saying that the “CACHED” status reflected in the VSTScannerMaster.log is plug-in driven, and not VSTScanner driven?
Meaning, a plugin which disables caching and forces itself to be scanned every time can still reflect “CACHED” in your log, even if the scanning process would normally reflect how long this scan took?
The “CACHED” status is not telling us that you’ve previously, successfully scanned that plugin already and thus skipped it in subsequent scans irrespective of what the plug-in’s “caching disabled” flag says?
Thanks.
1 Like
I’m not sure of the exact mechanism, but I think effectively the flag says ‘scan me every time because I might have a different number of plugins to last time’. The scan has two purposes:
- provides protection against a plugin that crashes on startup
- allows Cubase to build a list of available plugins and their metadata, since 1 dll can host multiple plugins
I can’t remember without looking at the code what the exact meaning of ‘CACHED’ means in the log – it may just mean ‘finished this entry’
Thanks. So then in theory the scanning log could still show something as being cached (and thus implying a 0ms scan time) even though the plug-in was in fact scanned and even took 20000ms to complete? That seems counter to the purpose of the log file as I understood the original description. Am I missing something? Thanks again!
I’m not in a position to check the source at the moment. I don’t think I had any Waves plugins to test on when I added that extra logging, so I’m not sure whether they would report as being ‘CACHED’ or not. Generally I think if the cache doesn’t yet exist or if the plugin has a newer timestamp than the previous scan then it will always be scanned, otherwise it will use the existing entry.
2 Likes
A little later…
Hi Glenn, glad to see you are still at it.
I have this exact issue. About 300 licenses on iLok and narrowed it down to these:
All UADx are fine, All Softube are fine, as are all others on iLok
All Waves 16 are fine, (not on iLok they are on a USB stick).
So far:
Nugen / Pulsar / Liquidsonics
- All cause the scanner to hang
- All have valid licenses on iLok
- All were working earlier today
1 Like
OK I have some more info.
It seems that this is a known (but very recent) issue caused by the latest Pace toolkit, plugins built with that version are locking up Cubase / Nuendo VST3 scanner. (And others, I also had the same issue with Luna fwiw).
This is why you will probably find (like me) that it only happens on newer versions of iLok protected plugins, (that were built using the iLok latest toolkit.)
So, I guess there’s not much more that can be done right now except, roll back to slightly older versions of the plugins and wait for the people at iLok and various Plugin Devs to sort it out.
3 Likes
I don’t use Nugen or Pulsar plugins, but I do have several from Liquidsonics.
Whenever the Ilok ZDT refreshes (annually), I always have to reactivate a plugin or two when I start Cubase / Nuendo the first time after the refresh. One of those plugins is always from Liquidsonics (and not always the same one). I have no idea why.
I do get a warning message from Ilok though, the scanner does not hang.
1 Like
I have suspected something like this might be the case as I didn’t recall having experienced something like this for the last few years. I have also tried going back multiple ilok versions on the client, but that didn’t help unfortunately. For me, it’s primarily Softube plugins though. Thats likely because I have a lot of them. When and at what plugin exactly it freezes, is totally random from my observations as long as it’s an ilok protected plugin that checks for ilok authorization during scanning. I’ve had one freeze on IPA25 from Pulsar as well.
I use Pulsar’s Echorec quite a bit and also have the W495 eq installed. Not had a single issue here with them. Mine are on a dongle if that matters.. Have honestly not had one bit of trouble with iLok in the 10+ years I’ve been using it.
Same here.