Dorico doesn't seem to like sleeping

A couple of time now, when I wake my Mac up from sleep, with Dorico open and a project loaded - it seems to stall out. This last time I tried force quitting Dorico and reopen the file. It recovered the file, but nothing would play - even though it seemed like everything was loaded and ready to go. A quick restart and open the same project again - no problems.

Here is a crash report.
Dorico (1.11 MB)

Thanks, for the diagnostics report. There are two crash dumps of the audio engine contained. We will have a look and report later.

Just had another crash. Here is the Report if it helps.
Dorico (1.3 MB)

Sure it helps. But this time it was a crash in Dorico itself. We’ll have a look tomorrow when back to the office.

Thanks you.

this happens all the time to me in windows 10-- the audio engine seems to crash when going into sleep mode. I’ve learnt to just shut down the programme when finishing a session. Happened quite a lot in Sibelius as well but Dorico is even worse. As the OP says, Force quit does not bring back the audio and the VST must be fully shut down. Often you seem to need to start the project once more then quit without saving and then restart Dorico a second time. I assumed that lots of people find the same but if there is a solution, I would of course be delighted to hear of it as it would save time.

The Dorico crash you’re experiencing is due to a problem with the ‘Wind band’ bracketing style, which we have already fixed internally. Don’t choose that for layouts with only a single player and/or instrument.

Hmmm. I didn’t know I did that. How do I undo this?

If you can’t open the project without it crashing, zip it up and attach it here or email it to me at d dot spreadbury at steinberg dot de and I’ll fix it for you.

Assuming you can, however, open the project, then go to Layout Options, click the button to select all the part layouts in the list on the left-hand side, then go to the Brackets and Braces page of the dialog, and choose ‘Orchestral’ as the bracketing approach. That should sort it out.

Regarding the audio engine crash dumps:
The first crash is caused by Keyscape. Please notify Spectrasonics about it, because there is nothing that we can do about. Also, this crash does not have anything to do with sleeping. Dorico was up and running and you opened a new project when the crash happened.

The second crash however is indeed in our audio engine. The pattern of the stack trace I remember having seen before, but only once and we never got to the bottom of it, since it was not reproducible for us. And also here, from what I see in the log files, the crash did not happen while waking from sleep. Dorico and the audio engine were up and running for nearly 10 minutes and you were adding notes and also playing back when it happened.
So I assume that you later send Dorico to sleep and that upon waking then it became unresponsive, because it was waiting for an audio engine that crashed already before going to sleep.

The next time it happens, please make a note at what time roughly you send Dorico to sleep and wake up again.

Since you have this consistently, could you do this on purpose again? Please make a note when you send Dorico to sleep and wake up again. Then do Help > Create Diagnostics Report and post here the on your desktop created zip file. Thanks

I first tried a simple test project using VSL, sent it to sleep and it woke up OK. Then tried the project I’ve been working on which is VSL + EWQL Symphonic Choirs. Froze after being c. 10 minutes in sleep mode around 12.55 to 13.05, I think, but you can presumably check the time as it was immediately before creating the diagnostic. It seems from Task Manager that the e-licenser crashed. Thought I would then try with the iLok dongle is a different USB port. Had no problems this time. Switched back to the original port. Still OK. As both of these were in sleep mode only 1-2 mins, I thought the duration could play a role. Tried a good 10 minutes with the test VSL only project but this was still OK.

As I’ve been getting pretty persistent failures when both a) using the EWQL software with iLOk and b) leaving the PC in sleep for a considerable length of time, it seems the combination provides the most reliable crashes. I have had this issue before without using Symphonic Choirs but it seems much less consistent and may not have experienced it since updating to 3.1.

Anyway, it will be interesting to see what you come up with, Ulf. I should point out that, unlike with a number of others, I have not in general had any other issues with e-licenser.

Dorico (607 KB)

Hi David, this is very confusing to me. So you say your computer was sleeping from 12:55 to 13:05, right? But the Dorico and Audio Engine log still show activity during that time. Also, there is no crash dump contained in the diagnostics.

This is an excerpt of the Dorico log:
2020-01-23 12:51:04.030 : notifyPostCommandExecute: Play.StartOrStop?PlayFromLocation=kPlayhead (56 ms)
2020-01-23 12:52:28.721 : Executing command: Play.StartOrStop?PlayFromLocation=kPlayhead
2020-01-23 12:52:28.747 : addEventsForAudition() adding 288 events to buffer #:0
2020-01-23 12:52:28.751 : notifyPostCommandExecute: Play.StartOrStop?PlayFromLocation=kPlayhead (30 ms)
2020-01-23 13:00:31.501 : Posting command (requested): File.AutoSave Post=true
2020-01-23 13:00:31.501 : Executing command: File.AutoSave
2020-01-23 13:01:20.169 : Posting command (force): File.Exit
2020-01-23 13:01:45.247 : Posting command (force): File.Close OpenScoreID=4, ScoreLayoutViewContainerID=4, Post=true
2020-01-23 13:03:56.346 : notifyPostCommandExecute: File.AutoSave (204843 ms)
2020-01-23 13:03:56.346 : Error: product not activated or feature not available
Error: product not activated or feature not available
2020-01-23 13:04:07.896 : Executing command: File.Exit
2020-01-23 13:04:07.925 : Closing document session: 4
2020-01-23 13:04:07.925 : Deactivating document: 4
2020-01-23 13:04:09.721 : AppControllerHost terminating
2020-01-23 13:04:09.880 : Audio engine: Terminated
2020-01-23 13:04:09.886 : notifyPostCommandExecute: File.Exit (1990 ms)
2020-01-23 13:04:09.887 : WARNING: audio device not responding - check device settings
2020-01-23 13:04:09.887 : Executing command: File.Close?OpenScoreID=4&ScoreLayoutViewContainerID=4
2020-01-23 13:04:09.889 : notifyPostCommandExecute: File.Close?OpenScoreID=4&ScoreLayoutViewContainerID=4 (3 ms)
2020-01-23 13:04:09.889 : AppControllerHost terminating
2020-01-23 13:04:09.902 : AppControllerHost terminating
2020-01-23 13:04:11.565 : Application terminated

So you see it ran until 13:04 and terminated gracefully.
Something identical I see from the Audio Engine side:

2020-01-23 12:52:28 : setTransportRunning: Stop2020-01-23 13:04:07 : close AudioDeviceDocument 1: ASIO Fireface USB, 44100.000000, suspended 0
2020-01-23 13:04:07 : close EventDeviceDocument 1
2020-01-23 13:04:08 : close MixerDocument 1
2020-01-23 13:04:08 : ClientCallback::audioDeviceBaiosChange: resyncRequested
2020-01-23 13:04:09 : ChangeEvent::Type::quitAppWanted
2020-01-23 13:04:09 : Server will exit
2020-01-23 13:04:09 : AudioEngineBackend => engineWillExit
2020-01-23 13:04:09 : VSTAudioEngine Released…

And at 13:05 I see a normal start-up of both.
So from what I see, Dorico seems to be not sleeping. Maybe the lid is closed but it is still active.
To me it even looks like the app is terminating gracefully when you open the lid again.
But this does not fit with your experience of freezing.
What happened when exactly?
Would be nice if you could repeat and be more precise about the timing information.
Many thanks

And, eh, you know that Dorico 3.5 is available and for free for all Dorico 3 users?

Thanks Daniel -

I am able to open the project and when I did as you instructed, it seems like the option you mentioned is already selected? I clicked it again just to be sure. I ask only to learn if this is showing what I think it is. Or, just because it is outlined in blue, doesn’t mean that is the active mode for all the parts.

And, the Apply button isn’t active, so I am assuming it is the selected type.

I think you are right about the use of EWQL means that It/Dorico doesn’t really sleep. One indicator I have is the heat my MacBook Pro generates - stays pretty hot unless I shut Dorico down. For me, EWQL with Dorico gets out of sorts occasionally but regularly - not often enough to be a major impediment but often enough to annoy. (Don’t get me wrong, EWQL in general is awesome)

Specifically, the EWQL instance stops creating audio. You can see that MIDI is being sent from Dorico, you can see that the keys on the plugin itself move, you can hear non EWQL instruments play, but you are done unless you restart the whole computer. Restarting Dorico won’t do it. Its like the VST itself crashed and you have to force it to completely unload itself.

Not sure if it matters, but I stream the samples USB c-to-c from an external SSD. Maybe next time I will try purging and reloading the sample data.

Ulf, Dorico itself did not seem to crash but e-licenser quitting made it unresponsive. When end tasking the e-licenser, Dorico then quit automatically but, as you say, probably gracefully. The line 2020-01-23 13:03:56.346 : Error: product not activated or feature not available was the message I got when end tasking the e-licenser so it seems to me that the timing makes some sense but I’m afraid I forgot to write down the exact time and it might have been a bit different. Also I see your point that if windows was really in sleep mode, I wouldn’t expect Dorico to log anything during this period. I should point out that I use a desktop so use the windows sleep mode directly.

OK, tried again. Opened the Am Abendrot project including choir. Windows put to sleep at 15.09. At 17.13, I resumed windows and had the same behaviour as before. This time, though, I saw a dialog “Dorico LE3 connection to protection device lost”. I suspect you’ve seen a few of these! When quitting the dialog (as opposed to forcibly end task the protection device as previously), Dorico resumed with full functionality and I did a normal manual shut down after creating a new Diagnostics at 17.24. This behaviour is probably the same as before expect I didn’t notice the dialog which soon buries itself. That might account for the lack of a real Dorico crash.

I’m sure this is different from under 3.0 when I definitely sometimes had audio engine errors. I’m not quite sure what you mean by upgrading to 3.5 but rather suspect that was a typo. I’ve used 3.1 since the day it was released.
Dorico (595 KB)

If you need me to look at it further, please zip it up and attach it here together with details of how to reproduce the crash. I’m happy to do so, but can’t do everything by guesswork.

Thanks Daniel -

I don’t want to add more to your already full plate. It seems to be working now. If i run into more issues, i will come back to this thread. I just wanted to be sure I understood what you were telling me.


Hi David, thanks for trying again. And this time it was really sleeping as expected because there are no log messages for around 2 hours:
2020-01-23 15:08:48.432 : notifyPostCommandExecute: File.AutoSave (16 ms)
2020-01-23 17:12:51.517 : Posting command (requested): File.AutoSave Post=true

But the hint with the eLicenser crashing is a good one. We’ll further investigate into that one. That could also explain the trouble that also other people have with the eLicenser (and find so annoying.)

And of course, you are right, sorry, I got confused with the version numbers. 3.1 is the one that just got released.

Hi Ulf,
I haven’t been plagued by eLicenser issues anything like as much as some others but if my test helps you get closer to what’s going on then of course I’m happy. It may be that I can now reliably recover from what seems to be freezing after sleep mode but anyway it’s not a huge issue personally.

By the way, when I upgraded to windows 1909, Dorico 3.1 initially didn’t work (license error) until I installed the latest eLicenser update (the updates seem pretty frequent!) after which no problems. As this increasingly gets rolled out you may find others in the same boat