All “undo” actions take at least 1000ms to complete. I understand and can tolerate some lag due to layout computations, but having to wait 1-2 seconds for every single undo step, including every single select and deselect action, is a huge drag and makes Dorico nearly unusable. Generally speaking, I don’t think undo should take any longer than the action it undoes did in the first place, let alone 10+ times longer, especially for an action that doesn’t affect the layout at all.
2025-03-06 16:57:06.659 [info] Executing command: View.CentreSelection?Force=0
2025-03-06 16:57:06.700 [info] notifyPostCommandExecute: View.CentreSelection?Force=0 (41 ms)
2025-03-06 16:57:07.544 [info] Executing command: Edit.Undo
2025-03-06 16:57:09.349 [info] Posting command (force): View.CentreSelection Force=0
2025-03-06 16:57:09.359 [info] notifyPostCommandExecute: Edit.Undo (1815 ms)
I haven’t seen anyone else having this issue on the forum. Most of the posts about how slow Dorico is conclude with someone saying “that’s just how Dorico is because it has to recalculate everything all the time” and recommending just not making big files (implying long-form orchestral music is just not in the feature scope??). Regardless, none of the excuses or solutions explain why the select action, which takes a reasonable amount of time, takes so long to undo.
Other info:
- Ryzen 7 3700X 8-core 4.05GHz, Geforce RTX 2060 Super, 32GB RAM
- Windows 10 Pro 22H2, Dorico 5.1.81.2225
- ~1000 measures, ~45 parts, galley view, active layout only includes the 9 parts with any content thus far
- Turning off playback doesn’t help, nor does locking the layout.
- The task manager shows no spikes in hardware activity nor any resources at full capacity.
It does seem to scale with the amount of objects in the parts in the layout. A single part has a reasonable delay, a second part with the same amount of activity has a more noticeable but not awful delay, and so on, but the 9-part layout and the full score where all the rest of the parts are empty have about the same nearly 2 second delay. Perhaps looking up an object’s location based on the undo record is a much slower operation than doing so based on its location on the screen?
Anyway, just wanted to put this out there. With an issue like this, and the slowness in general, I couldn’t imagine trying to use Dorico professionally.
1 Like
Deeply disappointed that this has gotten no response or even acknowledgement, especially with how responsive people claim this forum is.
As an update, as the number of populated parts in the project I’ve been working on has increased (there are now 28 parts with notes in them), so has the undo delay. It now takes 6 seconds for Dorico to handle undoing a selection.
I’ve been getting by by manually undoing whatever I’m trying to undo (deleting things, moving them back where they were, etc.) and just pretending there is no undo function.
1 Like
I’m sorry people haven’t responded to your thread until now. Is there any way you could create a diagnostics report and attach that along with a snippet of your project to this thread? That will give the devs a comprehensive overview of what might be going on.
1 Like
Hi @electrosymphonic, and welcome to the Forum (even if I am a little late).
Did you tried to choose the Silent Playback template, save your file, closing and reopening it (and also Dorico itself)?
Could you tell also more about what Libraries/Playback Template/Expression maps are you using?
It would for sure be interesting if you could post your Dorico file (that present this issues), so that we (and the Team) can see the reaction times on our systems, to see if the problem is within your system or with the file itself, or what else. (If you are worried about your music, you can Select all, then use the Transform>Pitches functionalities that you find in menu Edit, to make your music unrecognisable 
)
2 Likes
Thanks for your reply!
Here’s the score and the diagnostic files:
Also sprach Zarathustra (reduced).dorico (2.1 MB)
Dorico Diagnostics.zip (2.0 MB)
With the brass it’s 7 MB so I made a copy with just the woodwinds. It’s just Strauss, so no need to obfuscate 
Among other things, I’ve been copying it as a project to figure out how to use Dorico. As you can see, I’ve been mostly successful, though I’m finding that there are a few things that require hacky and buggy workarounds, most notably the 3/2=9/4 substitute meters. There are a lot of annoying side effects every time I insert the “pickup measure” workaround (yes, it’s a workaround, not a solution) in the next part that needs it–but I digress…
I’m not sure about the libraries and such, but I haven’t messed with much aside from a few notation/engraving behaviors (like whether to use dotted rests and where to use ties, etc.). I have been using the full Iconica Sketch et al. playback template, though I had to manually set up the e-flat clarinet (on the HSO clarinet, which has much more of the needed range; Strauss really pushes every instrument to its maximum…) and also the organ (I used the ARIA player because its Hauptwerk isn’t as offensive on the opening pedal; I do wish there was support for dynamics on the organ…), which isn’t in the reduced sample. I did set it to Silent for the upload, and I didn’t see any improvement. After doing that, I restarted Dorico and it may have helped a tiny bit, but not much.
Let me know if you need any more info.
Hi @electrosymphonic, and thank you for the file.
It is indeed a massive Project, and I also experience some lagging, as you describe (iMac 27" 2022, 3,6 GHz 10-Core Intel Core i9).
I tried to split the piece into 4 flows and assign every flow to a separate layout (I also deleted all parts layouts). Doing so, when working on the separated-flows layouts, the lagging are almost totally gone (only the 4th layout is longer and has a little more lagging then the others, but much less then a second for undo for example).
This would probably be a good strategical way of working: write the piece in chunks (separate flows) assigned to separate layouts, and then at the end of music input, copy all into one single flow, assigned to the Full Score layout, for final adjustments (the steps of maybe deleting all parts layouts, and certainly lock the layout and work in Galley view are optional).
Here the file with splitted flows, in case you or someone wants to experiment and compare the behaviour with your original file:
test strauss-splitted flows.dorico (3.0 MB)
I am sure that someone from the Team will also have a look at your original project, and can tell more about the lagging issue.
1 Like