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.
I understand.
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.
NotePerformer64.dll probably won’t work without our supplemental files, but the trial version includes everything and uses the same OpenGL code.
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.
Hello all,
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.
Thanks so much for your help!
Welcome to the forum @mrdixon .
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
Thanks for your reply!
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:
C:\Program Files\Common Files\VST2\NotePerformer64.dll
Hi @mrdixon , if that is the only output then it seems that the scanner is actually hanging, and then most likely it is the very same issue, namely that NotePerformer hangs in that AMD driver DLL. In order to make 100% sure please follow the instructions from the second link in my previous posting. Thanks
Hi @Wallander , this is interesting:
I just had a user reporting playback problems and the diagnostics showed plenty of crash dumps.
The dumps all pointed at atio6axx.dll as the location of crash.
Now, the user has also NotePerformer installed, but from the callstack in the debugger I can’t see from where atio6axx.dll was called, so it could also be another plug-in, but I think chances are high that also in this case NP is involved again. Maybe with the NP symbols in place the debugger shows a little bit more. The other thread is this one and you could also get the diagnostics from there and try to load the audio engine dumps (if you have the time and nerve, just a suggestion 
)
[ Edit: Well, if you look at development of the other thread, it is more likely to be a problem with the Pigment-plug-in from Arturia, so don’t waste time on it. ]
I wasn’t able to produce the call stack, unfortunately.
AMD has a symbols server, but I couldn’t find this version of atio6axx.dll. You’re much better at PC than I am, so you might have better luck:
https://download.amd.com/dir/bin
Looking at the logs from Dorico Diagnostics, Dorico accepted NotePerformer64.dll. Still, NotePerformer could cause the crash. With that being said, many plugin developers, like FabFilter and Waves, use OpenGL because it allows high-performance drawing that doesn’t halt the main thread or reduce audio performance. There may be differences in the details, but we all load the same OpenGL driver and call the same code in the driver.
I’m going to see if we can set up a system with an incompatible AMD driver.
Meanwhile, if the user creates the “C:\np_use_software_rendering.txt” file and rescans NotePerformer, OpenGL-related problem should go away, as far as NotePerformer goes. The existence of that file triggers a backdoor that will make NotePerformer use the GDI Generic OpenGL driver, a software OpenGL graphics driver included with Windows.
Hi @Wallander , I also could not find the matching version on the AMD server. Don’t know, seems that it is an intermediate or not officially released version.
We’ve ordered a system with an identical RX 580 card. Can I ask precisely what Adrenalin/Driver version you are running?
We want to duplicate your setup.
I’m, sorry that I haven’t had time to run the gDEBugger. It’s on my list, but if you’re going to try to reproduce the problem, that would be much better.
I switched to the “Pro” version of Adrenaline. It is version 22.Q4. I’m not sure what version I had of the non-Pro Adrenaline, but it was the latest as of when I posted my earlier comments.
That should be Adrenalin 22.11.2 then. 
Don’t worry about gDebugger. We’ll take care of that from here.