Hi @mducharme , thanks a lot.
And yes, that is exactly the stuff we are after. Other users also had this experience with some plug-ins that would stall the scanner in the first run and then at the second time it will just go through. It’s not only Opus that is doing this, but also other plugs like EastWest Spaces2 has been reported.
I’m already in contact with the developers to try to find out what it is, that makes the plug-in hang our scanner.
Another interesting point with you is, of the around 400 plug-ins you have, roughly 40 of them take longer than 1 sec to scan. The highest contender was Kontakt with nearly 4 seconds.
As I said, we need to find out more about these scanning times by help of the third parties’ developers.
But it is good, because we are starting out and already getting the first new insights.
Thanks for all your support.
Cheers,
Ulf
That’s odd. Your PC is fairly similar to mine, except for a slightly older CPU, but I have never had Opus hang completely. It’s slow in scanning, similar to Kontakt, but it does finish.
Right, @Nickie_Foenshauge , that’s the other point that we need to find out: Why does it happen on some machines but not on others? But as I just said, we are starting out and begin the investigations.
I never had it hang (to my knowledge) prior to a few weeks ago. Although before that, I also did not know that I could add the “command line” column to Windows Task Manager to see what exact vst3 filename the vst3 scanner was scanning at that moment. So it’s possible that it was happening before, but I did not know. I recently updated Opus because I bought Silk in the black friday sale.
It definitely did hang - I let it run for about 2 minutes before going in and killing it. It shouldn’t take 2 minutes just to scan Opus.vst3.
One odd thing I’ve noticed with both Spaces II and Opus is the discrepancy between the file-change date, as reported by Explorer, and the build-date, that the plugins report.
Compare the Last Changed dates
with the build date of
Spaces II
and Opus
Apparently they were built almost a year later than the files were last changed!
I noticed that when I did my scan tests, sometimes Opus ended up in the ‘blacklist’ and sometimes it didn’t. I think that was for the Cubase 14 scans. Nothing in the blacklist on the Dorico scans.
I didn’t get any hard freezes or anything, and decent scan times…even starting with the EC.
For what it’s worth last time I used a Steinberg host and Opus together (Live 2), Opus seemed to work fine. It’s been a while since I’ve noticed issues with Opus in Dorico…and when I did I think it was more about iLok than Opus itself. Seems like once or twice a month that one needs to check home somehow to see if our Composer Cloud subscriptions are up to date. Once that goes through all is well?
That with the checking home is also our suspicion, but I did not hear from the East Westerns, yet.
At first I read that as “Best Westerns” like the North American hotel chain “Best Western”
True! And a few years ago I had a business trip to Vancouver and we stayed at the Best Western Hotel 
Cool - that’s actually just a few blocks from where I live (assuming the downtown one)
Yes, that one. I liked Vancouver a lot, it’s a good place to live at, seemed to me.
Good point about iLok. I just tried a rescan with my internet connection disabled, and sure enough, when the scanner reached Spaces it just hung. With Berlin Studio and Clasic Reverbs from Samplicity I got a pop-up notification about a missing internet connection and the option to either Retry or Quit. Once quit, the scanner continued.
Thanks for that test, @Nickie_Foenshauge . I will also do same with Cubase and see the outcome there…
Hey @Ulf :
Not trying to muddy the waters but,
I’m preparing for a brand new mac and in the process I removed all my Waves plugins.
on a whim I opened Dorico and lo and behold: no real wait time. The Dorico app booted right away and no warnings about the audio engine!
perhaps it is my machine but I thought I’d mention it in case these specific plugins are problematic.
Patt
Well, we know already that the Wave plugs are special in that they always require a scan on every single start up. There is the so called WaveShell plug-in, a wrapper around many plugs, where the license you hold determines what plug-ins you can actually see.
@Ulf I’m a new Cubase user who has been suffering the slow VST scanning symptoms as well. I’m not running into this issue with other DAWs on my system including current versions of Logic, Bitwig, and Live.
System Details
Mac Mini M1, 2020
16 GB Memory
256 GB Hard Drive (Internal)
4 TB OWC Express 1M2 (External)
Note: Library/Audio/Plugins/VST3/ symlinked from internal to external drive
Note: Cubase 14.app located on external drive
Mac OS Sequoia 15.6
Steinberg Cubase Pro 14.0.30 Build 324 (Apple Silicon) - Built on May 22 2025
When launching the app itself, once the scan wraps the app is 100% stable and exhibits no other problems.
I completed two series of test, each with five runs. A snapshot of the “CubaseCache” folder from my desktop for each run is included in the attached archive. When I’ve continued additional runs, the total count of plugins with “OK (CACHED)” continues to vary. The plugins that are flagged as cached does not seem to demonstrate a visible pattern either.
CubaseCacheSnapshots.zip (814.7 KB)
Here is a log of each test and run:
| Cache State | Test Series | VST Scan Run | MS | MS (Converted) | XML Records With “OK (CACHED)” |
|---|---|---|---|---|---|
| EC | 1 | 1 | 248080 | 4m 8s | n/a |
| FC | 1 | 2 | 59735 | 59s | 672 |
| FC | 1 | 3 | 138344 | 2m 18s | 452 |
| FC | 1 | 4 | 178995 | 2m 58s | 236 |
| FC | 1 | 5 | 156943 | 2m 36s | 318 |
| EC | 2 | 1 | 245229 | 4m 5s | n/a |
| FC | 2 | 2 | 78823 | 1m 18s | 660 |
| FC | 2 | 3 | 242311 | 4m 2s | 250 |
| FC | 2 | 4 | 205400 | 3m 25s | 204 |
| FC | 2 | 5 | 162703 | 2m 42 s | 318 |
Hi @mvanputt,
thanks for the data and the numbers are most unexpected.
Well, not for the very first run (empty cache) , because you have 960 plug-ins and there it is normal that it takes more than 4 min. But the weird part are the following scans. With the cache in place, it goes down to 1 min (also still expected), but why on subsequent runs it goes up again is more than weird. I need to discuss this with my colleague who built the vstscanner. I’ll come back to.