Running 5.1.81 on MacOS Sequoia. Twice now today, I have been editing a long score, with two versions of the same score (separate files) open at the same time. While switching between the two files, I begin to notice the spinning beach ball cursor appearing, first for a few seconds, then for a few more, and then finally it hangs indefinitely. If I force Dorico to quit, and then try to reopen, it hangs on initializing the Audio Engine and cannot start.
This happened first under Dorico 5.1.70, and so I updated my Dorico to 5.1.81 in hopes that this was a fixed bug. Unfortunately, it is not And during the update, I noted that apparently, the reason Dorico cannot connect to the Audio Engine is that there is a running instance of the processā¦ but since I do not know its name, I could not even safely stop it with a kill command from the Terminal.
A reboot will fix the problem, but how to prevent this in the first place? And while the cursor is spinning, is there any way to at least stop it from doing what it is trying to do (I tried Cmd-. and several other keystrokes, including Esc, to no avail)? I have now, twice today, lost over an hour of work to this problem.
When you switch between documents, the Audio engine deletes the VST data from the āout-goingā document, and loads the VSTs and samples for the āin-comingā document. That takes time.
If you switch back and forth while thatās still in progress, itās possible that the engine could hang.
There are application Preferences to either not load the samples in additional documents; or to ask you whether you want to āactivateā the audio, or not.
Does Dorico do this each time you switch between documents, or only the first time the āincomingā document is opened? It would seem to have to do it each time you switch, in order to explain what has been happening. And if it does it each time, why? The scores are nearly identical (different versions of the same score) - the VST in both documents is NotePerformer, and there are no samples to load. Why does it have to load and reload the VST each time?
Hi @krummholz, because it is simply too complex to work out the difference between two projects and to decide which difference can be ignored and which one is relevant. You already canāt compare the internal plug-in states, because it is just binary data, a blob of data that only the plug-in can properly interpret. And even if you do a binary compare, what if just one byte is different, can you ignore it or not? With a reasonable amount of programming and cpu power you canāt work it out, so it is better to scrape everything and start building a project setup from new.
And the audio engine process turns up as every other process in the Activity Monitor. It is called VST Audio Engine and can be killed like any other process, nothing special about it.
This is why you can set Dorico to not load the audio in secondary documents. And you can turn off the audio with the big power button next to the Play button.
If the audio isnāt activated in the secondary document, then you can switch back and forth effortlessly.
Thanks, but the difference or similarity between the two projects isnāt really relevant, is it? The VST in both projects is NotePerformer. Why does Dorico have to load a VST thatās already loaded, time and time again? Why doesnāt it just check, VST for this project loaded? If no, then load it; if yes, then do nothing. Shouldnāt take several seconds if already loaded. If it is unloading the VST before checking if the other project uses it, then that sounds brain-dead, imho.
And unfortunately, the number of processes in the Activity Monitor when Dorico is running is astronomical. Basically little different from ps -ef in Terminal. Too much to sift through. Only after killing Dorico was I able to find it, as it was the only process with the string āDoricoā in its name.
Yes, looks like Iām going to have to do thatā¦ though Iāve gone back and forth between two projects before and never encountered this problem until today.
Hi @krummholz, regarding Activity Monitor and the amount of processes.
Yes, there are tons of them , but for example the Process Name column you can sort by alphabet, just click on the column header. By that they donāt jump around any more and are easy to find. But the Activity Monitor has also a search function, have a look for the field with the magnifying glass.
Are there different NotePerformer configurations? As far as I know, if you select NotePerformer you get everything - itās not a sample library, itās all synthesized.
Oh sure, and I can pipe the output of ps -ef through grep (in Terminal), but that still leaves a ton of processes with āAudioā or āaudioā in the name.
In any case, I have Project Activation for subsequent projects set to āaskā, which should prevent this from happening again (I hope). The fact that the delays got gradually worse before hanging altogether - it wasnāt just a sudden, out of the blue hang - makes me suspect a memory leak or some other internal bug in Dorico. Iām relatively new to Dorico but have used Sibelius for years, also with NotePerformer, and never encountered this issue or anything similar. Other problems and bugs, yes, but nothing that caused me to lose hours of work.
As for losing hours of work, yeah thatās what I thought as well, and I have Dorico set to auto-save every 5 minutes. But twice yesterday, it apparently failed to save on schedule, or was unable to retrieve the saved project. The first time the hang occurred at about 1100, and the modification time on the project file was still 0934. No auto-recovered project was presented on next launch, either. The second time it hadnāt saved the project file but brought up a partial recovery, a version from about a half hour before the crash. The only difference I can think of is that the first time I rebooted the machine to get rid of the running audio engine, while the second time I was able to find and kill the audio engine process without rebooting the machine.
And during the update, I noted that apparently, the reason Dorico cannot connect to the Audio Engine is that there is a running instance of the processā¦ but since I do not know its name, I could not even safely stop it with a kill command from the Terminal.