After unloading all the scores, VSTAudioEngine is still using 6.56 GB memory. If I keep switching scores, its memory usage would accumulate until the OS warns the system memory is exhausted.
While it can be worked around by closing Dorico completely (and kill the VSTAudioEngine manually) and then reopening Dorico, it is a little bit annoying to do so. It would be nice if this issue gets fixed in a not-too-far future, say Dorico 7?
I am using Dorico 6.1.10.6078.
Are you sure that it would keep getting larger? What’s the largest you’ve seen it? I leave Dorico running for weeks on end, using a range of documents, and haven’t seen any problems.
It may retain some memory, perhaps, but that’s different from a memory leak.
The real test is: What’s your Memory Pressure? If memory pressure is still “in the green”, and low, then you have no problem.
Quitting Dorico should also kill the VST Engine. You shouldn’t need to kill it manually afterwards, as it won’t be there.
Yes. I have seen over 80 GB before it crashes. It depends on the VSTs in use. If you only use NotePerformer which is highly optimized and bug free, then you probably won’t hit this issue.
I just wanted to reproduce now, but VSTAudioEngine always crashes and Dorico becomes unresponsive once it hits around 70 GB, which is worse than previous versions. So I only capture the state after 2nd close and 3rd close of the all the score (only 1 score actually). You can see it uses 25 GB, and then 35 GB.
The problem is I receive OS warnings and got my applications randomly force closed. At this point VSTAudioEngine is killed by the OS.
This is my expectation as well, but the actual is that VSTAudioEngine (and sometimes Dorico as well) often hangs and prevents me from relaunching Dorico again.
My wish is Dorico can provide an option to restart the VSTAudioEngine when all the scores are closed or while I am switching among scores, instead of reusing the same instance.
Do you have lots of third-party VSTs? Perhaps one of them is the culprit?
Can you upload a Diagnostic Report here after this happens?
How have you got four instances of FireFox using all that memory? That’s probably as much a factor of the “out of memory” warnings as Dorico.
I don’t think Dorico is solely responsible for the memory leak. But as I said, I wish Dorico can provide an option to kill and restart the VSTAudioEngine automatically when all the scores are closed or while I am switching among scores, instead of reusing the same instance, so that I don’t have to manually restart Dorico. I am a Dorico user, not a QA of third-party VSTs.
It is clearly the VSTAudioEngine before crashing. I can reproduce even without any other application is opening.
If you can upload a Diagnostic Report, that will contain crash logs, and other relevant information.
Inevitably, using a computer requires some oversight and trouble-shooting.
Hi @sunnych , Ulf from Steinberg Engineering here. I’m not aware of the VSTAudioEngine causing big memory leaks and crashes. And as benwiggy mentioned it could be third party VST plug-ins that cause the leaking.
Therefore, I’d like you to load a project where you experience the leak and then do from Dorico’s main menu Help > Create Diagnostic Report. That creates a zip file on your desktop, please attach it to a reply here (or send me in a private message). Thanks
Sent you a message with the Diagnostic Report!
Yeah, but you brought the puppies home (the VST) 
. More seriously, when you get into various libraries, they provide their own independent memory and performance related controls which those vendors expect us to understand and use. If we know more about which VST and how you are using them, we may be able to help some more with the problem.
I’ll wager there are users here who understand certain library idiosyncrasies better than they do their spouses, and definitely better than their near adult children, sigh.
I guess we are slightly off-topic. Third-party VST could do everything bad. OK, I acknowledge all the performance issues and resource exhaustion are caused by them. I am not asking to improve the situation while these VSTs are in use.
But after unloading all the VSTs, Dorico should take back the control. You say third-party VSTs’ memory leak are not controllable? As a user, I can simply control by killing the VSTAudioEngine process. Could it be feasible for Dorico to help me control by killing VSTAudioEngine automatically rather than let me do manually, and then launch a new instance of VSTAudioEngine? Is this what Dorico could do and should do? This is the point of my post.
You can say I can change the way of using, not to use specific VSTs, ask the VST manufacturer to fix it, not to use any VSTs, not to open Firefox in the background, not to use Dorico, blah blah blah, to avoid the problem. That is not the focus. There is already a workaround for me.
Actually, I thought someone might be able help you avoid or mitigate the problem in the first place. Nobody is going to twist your arm.
Sorry @sunnych , workarounds are fine as long as there is no other solution for it, but the real problem should be properly fixed, be it on host or plug -in side.
See, I have also some other customers that use Opus, where the gui freezes in once you start playback. There is also a workaround and similarly Dorico could implement a shortcut to make it more convenient, but we are not going to do that. Instead I’m in contact with EastWest in order to sort it out and fix it properly. That’s the way to do it, anything else just leads to nowhere.
So we have to find out who is leaking memory and then approach the corresponding plug-in vendor(s). Or could even be that it’s our fault, then of course our engineers will need to solve it.
Understood. I have sent you the Diagnostic Report yesterday. I guess that should include a list of plugins I am using. Please let me know if you need the score as well.
Hi @sunnych , yes please, could you provide the project file. Thanks a bunch!
Hi everyone,
good news on this end.
I’ve been in contact with EastWest on this and they have identified and fixed a memory leak in Opus. The fix will come out with the next Opus update (whenever that might be).
Thanks again @sunnych for bringing forward the case.
