Hi everyone,
I had the same problem and thanks to this forum I could fix it!
Some points to add:
If the “scanVSTsOutput.txt” doesn´t appears in the desktop, check the route where the file is created (my route was %UserProfile%\OneDrive\Desktop\scanVSTsOutput.txt, instead of %UserProfile%\Desktop\scanVSTsOutput.txt)
There’s no need to delete files, go through multiple reboots, or install obsolete video drivers. The problem, by the way, is not limited to the Optional drivers.
In the Dorico , select Edit > Preferences > VST Plug-ins > Clear Audio Engine Cache, then exit Dorico.
In Device Manager, find the Display Adapter driver and select “Update Driver”.
Select “Browse my computer for drivers”.
Select “Let me pick from a list of available drivers…”.
Select the Microsoft Basic Display Adapter.
After the driver is installed, re-start Dorico—Note Performer will be properly scanned (no timeout, no black listing).
Exit Dorico.
In Device Manager, find the Display Adapter driver and select “Update Driver”.
Select “Search automatically for drivers”. The Radeon driver will be re-installed.
Re-start Dorico. No hang will occur and NotePerformer will work with the latest Radeon driver.
The conflict between the newer Radeon driver and NotePerformer only occurs during VST scanning. Only users trying to use NotePerformer for the first time, or anyone trying to re-scan their VSTs will have a problem.
You will have to repeat this sequence any time a re-scan is needed, of course.
This suggestion is a bit disappointing.
Dorico’s users aren’t necessarily software engineers and aren’t in the best position to fully describe the problem to AMD. We can’t debug Dorico to spot a hang in atio6xx.dll nor tell AMD exactly why and how atio6xx.dll is being called, information that AMD might need to fix the bug. The connection between a video driver and a VST scan would be opaque to most of us.
Most of us would only be able to tell AMD that a program called Dorico hangs when scanning for VSTs , that a Dorico engineer claims that the problem is in a file called atio6xx.dll, and that the problem goes away when an earlier driver is used. They might reply that Dorico is probably just calling atio6xx.dll incorrectly and it’s not their problem, and how could we argue with that?
The two big video card companies are AMD and Nvidia. One would hope Dorico would have systems with video cards from both companies. I would suggest someone on Dorico’s team file a bug with AMD. If the Dorico team can’t reproduce the problem, it would still be more productive for them to contact AMD, as they could provide more context about the problem. Those of us able to reproduce the problem could test any fix.
We can’t afford to do that. We already struggle delivering the support for our own products. The problem is not our software here, it’s 3rd party, namely Wallander Instruments (NotePerformer) and AMD. It is the responsibility of the plug-in manufacturers to make their products work with us, so it would be fair to ask Wallander Instruments to file a bug report with AMD.
No one likes to waste their time documenting and reporting problems in other people’s software. Ironically, this is what your users do when they encounter a bug in Dorico.
Hangs are interesting problems. I worked on a project long ago where I was responsible for the subsystem that allowed others to interactively enter commands. Whenever there was a hang anywhere, the obvious symptom was that the user interface froze, so guess who got all the problem reports? I spent a lot of time tracing down problems in other people’s code.
The problem might be AMD’s. It might be Wallander’s. And it’s not impossible that it could be yours. Again, without knowledge of the code, the end user is the least useful person to report the problem.
In any case, it looks like Wallander is aware of the issue:
According to the thread below from the AMD forum, “AMD Adrenalin Software” causes an atio6axx.dll driver crash for just about any software using OpenGL. I don’t know if it’s the same crash, but the poster says the problem is resolved by uninstalling “AMD Adrenalin Software” and installing the driver manually.
If you can’t do that, please try creating the empty text file “C:\np_use_software_rendering.txt” and let me know the results. I created that NotePerformer backdoor to test Windows fallback rendering for non-compliant graphics cards. I think I left it in for the final build. If it works, the only drawback is that NotePerformer’s mixer graphics may update less smoothly and use a little more CPU.
EDIT: I see now that a previous poster already mentioned this solution. Unfortunately, we have little influence on AMD. The bug affects several high-profile programs, including Blender, Matlab, and Minecraft, so I am confident that AMD is aware of the issue. With OpenGL, programs only make basic calls, and the graphics driver implements the actual code for drawing graphics. Consequently, the code is different for every driver. We comply with the OpenGL standard (and use only the most basic and failsafe features of OpenGL 1.1 from the 1997 standard). Still, a manufacturer occasionally releases a faulty driver, which is the case here.
EDIT2: I don’t have an AMD card to try this on, but AMD drivers come in two different editions. The “Adrenalin Edition” is optimized for games, and the “Pro Edition” is optimized for stability. It may be worth trying the “Pro” version of your driver. It can be downloaded from AMD’s website.
This is clearly an exaggeration. I have plenty of programs that rely on OpenGL and atio6axx.dll doesn’t crash all of them (or any of them—Dorico catches the lack of response and moves on).
I uninstalled the Adrenaline Edition and installed the Pro Edition, which oddly still identifies itself in places as AMD Software Adrenalin Edition and elsewhere as the AMD Software PRO Edition. The problem still occurs.
I have no idea of AMD is aware of the problem. The bug report you pointed to is from May of 2021, so that bug may have been fixed long ago, or else the problem has been with us for 1.5 years and through several releases of the AMD software. I would not rely on them knowing about the issue with NotePerformer based on that bug report.
Your workaround is much faster than mine:
In the Dorico , select Edit > Preferences > VST Plug-ins > Clear Audio Engine Cache, then exit Dorico.
Create C:\np_use_software_rendering.txt.
Start Dorico—Note Performer will be properly scanned (no timeout, no black listing).
Exit Dorico.
Delete C:\np_use_software_rendering.txt.
Re-start Dorico. No hang will occur and NotePerformer will work with the latest Radeon driver, including either the Adrenaline or PRO Editions.
Until someone provides AMD with a clear bug report, the situation will continue to cause problems for users of AMD software (Adrenaline or PRO) + Dorico + NotePerformer. I will submit a bug to AMD pointing to this thread; I don’t know how effective this will be. What they want, of course, is a minimal series of steps that reproduces the problem.
I understand NotePerformer is not a huge company with funds to buy and test all sorts of video cards. If there is some information I can capture for you that you could use to provide AMD with a more useful bug report, PM me.
Hmm, does the error return if you clear the Dorico cache in this state? vst2scanner is only invoked the first time when the plug-in is scanned.
I’m only speculating, but atio6axx.dll might crash when invoked from a command line process rather than a windowed process. Vst2scanner is a command line process.
Can I ask exactly what graphics card you’re running?
If I understand your question properly, the answer is yes. Every time I go to the Dorico preferences, select “Clear Audio Engine Cache”, and restart Dorico, the problem re-occurs. Once the scanning is performed without error (using a workaround), then it no longer matters if the Adrenaline software is present or not.
There is no crash. There is a hang. Dorico notices, kills the hanging process, and blacklists the associated VST.
Radeon RX 580. It would be interesting to know if if the problem is card-specific or whether it affects everyone with the Adrenaline software.
I understand. It sounds like it only happens with vst2xscanner.
I’m going to attempt a fix for NotePerformer 4. I’m sure I can find a way to detect if the plug-in is launched in a command line process, detecting vst2xscanner. We could automatically select the software OpenGL driver for command line hosts. The choice of OpenGL driver is unimportant in that context.
For what it’s worth, I just submitted a problem report to AMD, pointing them to this thread. The submission process doesn’t generate a tracking number, and I don’t know if I will receive one in the future.
@Ulf, not to let Dorico completely off the hook, I found Dorico’s error message confusing when I first saw it. It could be improved. Here is the error message that Dorico reports (as copied from the OP):
Scanning
C:\Program Files\Common Files\VST2\NotePerformer64.dll
A timeout may have occurred. Check if the plug-in is displaying a message or click ‘Cancel’ to put the plug-in on the blacklist.
Here is my somewhat wordy re-write. I’m sure your technical writers can do better.
Scanning for VSTs…
The VST at C:\Program Files\Common Files\VST2\NotePerformer64.dll did not respond to a request to identify itself [or whatever it is was you were doing] in a reasonable amount of time.
Check your screen to see if the VST is asking you for something.
If you don’t see anything, click Blacklist to put the VST on the blacklist. You will not be able to use it. Contact the VST manufacturer to report the problem.
More information would be useful, but Steinberg can’t possibly produce that.
What’s happening here is that NotePerformer calls a standard OpenGL function that’s relayed to your driver, which freezes the entire process without notice. From Dorico’s point of view, it’s NotePerformer that freezes. From your point of view, it’s Dorico that freezes.
Only AMD can produce more information about the error. The best we can do is to try and avoid whatever is freezing the AMD driver, even if what we initially did was legal by the OpenGL standard.
I’m sure your bug report is as good. If you get a reply from AMD, let them know it’s a command-line process. I think that could be relevant.
It sounds as though you are saying that Dorico’s scanning process is a command-line process, and that this is useful for AMD to know. I’ve pointed them to this thread, so they might see this.
I understand that you are executing perfectly legal OpenGL functions. Even so, the specific set of commands, the order in which they are executed, and their parameters would be valuable for AMD. It’s unlike to be as simple as a single command that always fails—if it were, AMD would probably have received thousands of bug reports for it.
Since NotePerformer always runs into the problem and only during whatever happens during the VST2 scanning process, you might have some idea of where the problem might lie. Since you don’t have an AMD video card, it might be difficult for you to produce to create a simple test case to narrow down the problem or avoid it. But without information on exactly what commands are being executed, AMD will have a hard time fixing the problem.
If you know of some mechanisms for tracing OpenGL calls that I could enable during Dorico’s VST2 scanning (or better yet, only during NotePerformer’s response to the scanning), let me know.
Although I haven’t used it in many years, you might be able to see our OpenGL calls through “gDebugger” if you’re interested in trying that:
Since NotePerformer is a 2D application and complies with OpenGL 1.1, we make basic OpenGL calls. We select a pixel format, upload textures, and draw triangles.
Nevertheless, since the software rendering mode fixes the vst2scanner failure, and you can then delete the software rendering file, NotePerformer must be working with the AMD driver in Dorico if it only passes validation. I think our safest bet is to avoid the AMD driver in command-line mode. If we change the order of calls, there’s always a risk that it may cause drawing problems for another OpenGL driver.
Actually, it should be possible for AMD to reproduce that behaviour themselves, provided one hands them over two binaries, namely the vst2scanner.exe that can be found under C:\Program Files\Steinberg\Dorico4\VSTAudioEngine\Components and the NotePerformer64.dll that is under C:\Program Files\Common Files\VST2.
In a shell one can then invoke the scanner like this:
vst2xscanner.exe -p <path to NotePerformer64.dll>
This is also the way that Dorico invokes the scanner.
True, I just tried it on a PC where NotePerformer is not installed and it complains about missing files, so yes, it needs a full installation of NotePerformer. But the vst2xscanner.exe is self-contained and does run anywhere.
I’m receiving an error message identical to AragornK’s original post. I don’t know if the cause is the same, but our issues have so much in common that I think it’s better to post here than create a new thread.
I’m using (to my knowledge) the most recent versions of Dorico (4.3.11) and NotePerformer (3.3.2) on Windows 10. I do have AMD Adrenalin software & drivers; after uninstalling AMD Adrenalin, I tried reinstalling NotePerformer and received the same error message. Then I reinstalled with minimal software, repeated the process, and again received the same message.
I apologize for the lack of useful information - I’m not at all tech savvy and I’m not certain I’ve done anything correctly, but I’m happy to provide diagnostic reports and any other necessary info to resolve this issue and get NotePerformer working again.
Please follow the advice as I wrote here earlier in this thread.
If you do that and it is hanging, then please follow the instructions from here.
Thanks
The first option seemed to work, no hanging, and here are the contents of the file:
Found Dorico vers 4 and VAE vers 5
Using as input: “C:\Users\Michael\AppData\Roaming\Steinberg\Dorico 4 AudioEngine_64\Vst2xPlugin SearchPaths Dorico 4 AudioEngine.xml”
Using as VST2scanner: C:\Program Files\Steinberg\Dorico4\VSTAudioEngine\Components\vst2xscanner.exe
Using as VST3scanner: C:\Program Files\Steinberg\Dorico4\VSTAudioEngine\Components\vstscanner.exe
Tue 01/17/2023 21:36:09.41
VST2 plug-ins: