For certain files, Dorico freezes between the note selection and hearing the note’s articulation (10-30 seconds). Often these are relatively small files (string quartet only), but this behavior is not observed for all my active projects, only some. I have system track disabled and I’m in Gallery view. I’ve changed my playback template to the Halion library. Nothing seems to make a difference. It’s almost like Dorico is waiting on the GPU to highlight the note before it plays it. However, none of the processes or graphs in Process Explorer indicate an issue. Please advise. Thanks!
You say it only happens for certain files - would these files be particularly large, either in length or in numbers of players? It might be useful to see an example of one of the files that exhibits the issue.
Hi Richard. It doesn’t seem to do with the complexity, number of players or length of the file (#1). I can be working in one file just fine. And when I close it to open a new file (#2), the symptoms begin. From there, if I close file #2, and reopen file #1, it too starts exhibiting the same symptoms. If I close Dorico completely, and reopen file #2, it works fine…
I can think of two possibilities. One is that you aren’t allowing the sounds to load fully when you open a score - this can take a while, particularly if you’re swapping from another open score, as it has to unload all the sounds from the original score too. This seems unlikely, though, because you can see this happening - all the playback controls will be disabled until the sounds are loaded. The other possibility is that auto-save is taking a long time, which can sometimes happen if the project is long (in terms of pages) because it may be having to capture a thumbnail of the project. One thing to try, then, is to uncheck the “Generate preview thumbnails when saving” control in the Project Info dialog - that will stop thumbnails from being captured during auto-save.
There are other possibilities, but I’d try that out first and see if that does the trick.
Yep - I’m aware of the sounds loading before the transport controls are enabled. I do have autosave enabled but when this issue is happening, it doesn’t get better. The issue is not periodic. The only way to clear it is to relaunch Dorico or reboot. (at least as far as I’m aware).
In that case we’ll have to see an example of a score where it goes wrong, and ideally a diagnostics file that you’ve collected from a session in which the problem starts occurring.
A diagnostic file is attached higher in this thread. It was collected during one of these sessions.
I can attach a score no problem. But “where” it goes wrong = everywhere. When you click on any note, there is a 10-30 second delay before the note is highlighted. During that time, Dorico freezes.
Sorry about the delay in getting back to you. James, one of my more expert colleagues has suggested collecting some performance data as follows.
Download and install the latest version of “UIforETW”. This is a Google tool that wraps the Microsoft performance tracing framework, so it’s all totally legitimate and safe. It lives at Releases · google/UIforETW · GitHub, where you can find the download for the latest release in the column on the left; at the time of writing, it’s this: https://github.com/google/UIforETW/releases/download/v1.59/etwpackage1.59.zip Unpack the zip somewhere and run ‘UIforETW.exe’ to install the tool.
Get Dorico ready to do the slow operation.
Click ‘Start Tracing’ in UIforETW.
Switch back to Dorico and perform the slow operation.
Once the slow operation has finished, press Ctrl+Win+R to save the trace to a file. Add some comments to the ‘Trace information’ field if possible to indiciate what you did (i.e. “Changed selection from beat 1 to beat 2 in bar 254” or whatever).
Right-click the list of traces and select ‘Browse folder’. This will open Documents\etwtraces in Windows Explorer, where there will be a .etl file and a .txt file for each trace. Send these in to us in an email. If there are lots, compress them into a zip archive first to keep them all together.
It’s worth collecting a new diagnostics file just after doing this so we can marry up the different data. You can email it all to me at r dot lanyon at steinberg dot de.
We think that this might be some interaction between Dorico, the UI framework that Dorico is using (Qt) and the operating system’s “Ease of Access” features (things like Narrator, Magnifier etc.). Are you using any of Windows’ accessibility features? If so, is it possible to try turning them off one by one to see if you can work out whether one is triggering the problem? This is just as a diagnostic step - I’m not suggesting that it’s a permanent solution.
Another possibility suggested by the ETW traces is that it could be something to do with your graphics drivers. For example, we noticed you’re running both NVidia and Intel graphics drivers. Are you actually running multiple graphics cards at once? If not it may be worth trying to disable the one that’s not in use. Also, we have seen some previous cases where things are improved by turning off the audio output associated with a graphics card, if there is one and you’re not using it. (And you may need to disable power saving but it sounds like you’ve already done that.)
