How slow/fast does Dorico 3 perform on your Mac?

Dorico
#1

Hello all,

I use Dorico 2 and now 3 on a Mac Pro quad core from 2010 with 16Gb of Ram.

I find that Dorico needs a moment often to execute tasks.
Add a player 2-3 sec.
Add instrument 2-3 sec
Select all dynamics and delete 1-2 sec
Switching to one of the views (setup, write, engrave, play, print) 2-3 sec.

I could name more. Some steps just need a lot of thinking it seems.
Is this an average behavior for Dorico on a Mac of my age or is it possible that Something is wrong with my system?

Help is greatly appreciated.
Marc

#2

That doesn’t sound far off.

#3

It really depends on the size of the project. Dorico can be substantially quicker than that in small projects, as long as you don’t have loads of tabs/windows open at once. Setup mode actions require a lot of calculations behind the scenes, so they’re always a bit slow.

#4

The first three of your four examples involve reformatting the complete score (deleting dynamics is likely to change the vertical spacing between staves).

When you switch to a different view, Dorico formats the score in that view. It doesn’t continually update the formatting of every possible view after every edit, otherwise the response would be slow! For example, all the piano roll displays etc have to be generated with you switch to Play mode, they are not kept up to date while you are working in other modes.

#5

Hi Marc, have you seen some of the performance optimization tips mentioned in other threads? For instance, deleting all part layouts whilst composing or engraving can make a noticeable difference on orchestral scores. You can then generate the part layouts once everything is finalized. It works quite well in my experience. There are other tips available in recent (or recently-contributed-to) threads. Some of them can help quite a bit!

My machine is slightly younger than yours, and I have two more cores than you do, but for a lot of the examples you’ve listed, my machine is typically slower than yours. For example, switching modes takes me ~30 seconds on an orchestral project. (The one exception is Engrave mode, which switches over in a similar amount of time as you listed, possibly because I always work in page view with fixed systems/casting off per page, so there isn’t much, if any, to format when switching to Engrave.)

(EDIT to remove some mistaken thoughts about RAM. By accident, found an old thread where the team said 8GB total should work well, so this likely isn’t an issue in your case.)

If your internal HD is spinning platter by any chance, you might see improvement in Dorico by upgrading to an SSD. But I’m not particularly tech savvy, so take this all with a grain of salt and certainly don’t spend any money based on my passing thoughts!

Do check out some of the other threads if you haven’t already; they are probably worth your time. (EDIT: They’re not always easy to find, here’s one with a very comprehensive list, but I think I remember there being others worth tracking down as well: https://www.steinberg.net/forums/viewtopic.php?f=246&t=162988&p=872616#p872663)

#6

I have a 2018 Mac Mini, 6-core 3GHz i5 with 32Gb RAM. Yes, changing to Play or Print mode takes 1-2 seconds; Adding a player takes 2-3 seconds or so.

But generally, moving around the document and working is absolutely fine. If I do delete something, then yes, there will be a redraw ‘moment’. Changing Engraving Options can take 10 seconds to apply. I suspect that certain kinds of score elements, like Cues, divisi, condensing, maybe percussion? are slower to process than others.

However, I know that the team are looking at ways to improve performance. All-in-all, completing a score in Dorico is still faster than what I’d been using previously.

#7

I have a Mac Pro 6 core Xeon with 64GB RAM and would characterize the performance of Dorico to be generally sluggish, even on small projects, compared to other software, including any of the DAWs I have used. Admittedly, there is a lot going on in this app, but for all the claims of improved performance, it is by far the least responsive application I have used in recent years.

I still prefer it to other notation software for a variety of reasons, but it does require patience.

#8

Thank you for the info. Indeed I hadn’t checked out performance tips.
I should have and will now.
Kind of reassuring to hear that many of you have about the same performance as I do, despite newer machines.
So I might not have to upgrade my Mac, yet…

Yes, it requires patience sometimes, especially when you are working in a flow (not meaning the Dorico-flow :wink:
Its understandable that calculations might slow-down the process, but I am working very often in DAW’s with seem to have to calculate a lot all the time, and I never experience that kind of sluggishness in performance. Which keeps me wondering, why are most notation software suffering from that?
Finale 25 was so dreadfully slow that either had to kill myself, of ditch Finale and switch to Dorico.
Which I obviously did. (thankfully) and I love all the intuitive-ness of Dorico, but it could most definitely (and should) respond faster.

I was actually hoping that a faster machine would solve this, but helaas…

Could it be a graphic card thing? Would a faster GPU make a (significant) difference?

Cheers,
Marc



#9

You are totally right. DAW’s who it seems, are doing larger amounts of calculations in real time, even providing latency compensation on multi-track audio playback with plug-in-processing while recording plenty of audio at the same time!
It is puzzling to me why (all) notation software (Finale and SIbelius are a nightmare) are taking so long to execute (apparently) simple adjustments.

Why does changing from a part layout to a full score-layout in a orchestral piece takes 8-9 seconds in Dorico?
Generating the print-preview of the same orchestral condensed score takes 20 seconds. (I first thought the program crashed.)
When you press cmd-5 instead of cmd-4 by accident (going to print instead of play) and Dorico makes you wait for 20sec before you can go back to play (another 4-5 sec wait), I mean. Wow! That is a serious lag.
Why does the fader on the mixer lag behind the mouse movement and stutter? Isn’t that mixer based on Cubase code? Shouldn’t that move as smooth as the Cubase, Logic or Pro tools faders?
Just wondering here.
Faster performance is my number one wishlist for future updates. Anything else is totally secondary, when working for long hours on a large project with deadlines coming up.


#10

I must agree with you.
I’m doing whole shows alle the time - around 30 to 40 flows - and I will join in the wish for a faster experience.
Could it be done by restricting the calculation of layout to only flows just previous/after the flow that are being edited?
And keeping the overall/final calculating to be manual invoked. :slight_smile:

#11

As I understand it, Dorico’s basically designed to calculate entire layouts on the fly. Switch from Galley View to Page View? That’s a recalculation. Switch from anywhere to Print mode? That’s a recalculation (because your paper size in print mode may be different to your page size in Layout Options). Switch to Play mode? That’s a recalculation.

It’s all very well having 32 processors but if Dorico has to calculate a layout from left to right, it can’t process in parallel. It doesn’t know what’s on page two until it’s sorted out page one.

Dorico evidently does process in parallel, or there wouldn’t be such a huge difference between the way my dual-core and quad-core computers handle Dorico projects.

If you have particularly laggy projects, it might be worth sending them in so that the development team can add them to their bank of test files. Without real-world test files, the bottlenecks won’t necessarily be discovered.

#12

Dorico is not a DAW, and the performance characteristics are completely different. In a DAW, edits are usually instantaneous because all you’re doing is making changes to effectively a list of MIDI events. A DAW doesn’t need to do much to keep the GUI up to date because there’s not much calculation involved in showing a list of MIDI events.

Dorico doesn’t store MIDI data. It doesn’t store bars, staves or pages either. It has a low level representation of all the objects in a score and all the bars, staves, pages and MIDI notes are dynamically calculated from the source data. This is necessary so that can work out how to format each Layout for each combination of players, plus dynamically reformat for page view or galley view. Condensing wouldn’t work without it. Every edit you make has to pass through many calculations to work out how it affects the overall layout. Changing the pitch of a single note can set in progress a chain of changes that may push a bar onto the next system, which may cause another bar to be pushed onto the next page, which changes the instrument change decision points. The Dorico notation engine has a number of short-circuits so that if it determines that an edit won’t affect things beyond a certain point then can stop processing. There are something like 100 separate processing phases that are required to turn low level events into a score.

We are constantly looking at improvements we can make, and we know of a number of specific things that are on our list that reduce the amount of (re)processing that has to be done. But the bottom line is that during the course of editing the score, it is necessarily doing a huge amount of work. You can’t compare it to a DAW because they only do that processing during playback (and in any case, as soon as you play back then Dorico does do all that same work too). You also can’t compare it to the speed of other notation applications because it’s doing an order of magnitude more work to ensure that things are well-spaced and collisions are minimised.

#13

If ALL notation software finds layout a time-consuming operation, then perhaps it’s not as simple as you imagine it to be?

You can launch Activity Monitor and see whether Dorico is maxing out your GPU or CPU. (I doubt it is.)

The problem with “saving calculations until later” is that invariably people will make edits on what they see, not remembering that they’ve got some more changes pending. Finale’s “Automatic Update Layout” switch is the cause of much user aggravation, and that stems from a time of 16-bit CPUs.

Paul and Leo have both given excellent insights into the problem: I’m confident that things will improve. At the very least, the problem may be reduced as future hardware gets more powerful.

#14

Just an idea, would it be possible to speed up processing by allowing more localized calculations when enabling the “X number of bars per system” property? (in conjunction with X number of systems per page). That way its easy to figure out that if there are only 4 bars per page, and you’re in bar 9, you’re defacto on page 3 and you only need to recalculate page 3 (bars 9-12)? (if you’re working on an orchestral score, for example) Perhaps this type of focused processing could allow for faster interaction, and then full recalcs would only be necessary when turning the feature off or changing the setting.

#15

I have absolutely no data on this, but I wonder what percentage of users employ fixed casting off. I imagine it’s a significant minority.

#16

I have tried that pianoleo, I didn’t received any info if the developpers had found something special in my project that could tell why it was so slow performing.
I would assume that calculation of layout often is done on the remaining part of a score, and that would imply that the last flow in a collection would be faster to recalculate, but I havn’t seen that.

I find it a difficult subject to discuss, because I’m just a musician, so how do I know?
But I must say that among all the apps that I use daily in my studio Dorico is the slowest horse in the stable. And I wish it was faster - much faster.
I was one the first composers in Denmark to use computer - Atari - to create a score for The Danish Radio Orchestra back in 1985. I remember that going from the key of F major to Ab major in a full score could take as long as making the coffee - and drinking it. To day it’s much faster of course, but I REALLY wish you could make some improvements.
Thanks!

#17

Take a look on this little video showing how long time it takes to resize a text frame in Dorico:https://www.dropbox.com/s/ddagqqnvonuwu7f/Resize%20text%20frame%20Dorico%203.mp4?dl=0

#18

In answer to your previous post, Stig, I didn’t say “send in projects so that the developers can write you a nice message back explaining why your project’s slow”, and I certainly didn’t mean it! I meant send in your project so that it gets added to a bank of test files, so that optimisations may be made based on patterns noticed in a whole group of projects.

As to your most recent message, your video is a perfect demonstration of why the OP’s question “How slow/fast does Dorico 3 perform on your Mac” is such a difficult question. If there was a control - one project - sent out to many people, and a standardised list of questions asked - then some meaningful data could be gleaned. Without seeing your video, I couldn’t possibly know that every page from page 4 onwards in that layout has some sort of page override. Every override slows down Dorico.

#19

I’ve occasionally wondered something similar, as 4 bars per page is exactly how I work 99% of the time. (Basically, if you’ve ever seen anything in Herb Spencer’s hand, that’s the approach that makes sense to me, whether I’m on pen & paper or Dorico. I’ve tried other approaches and they just drive me crazy for some reason.)

I know nothing of programming software, etc., but my hunch is that, even if people who work like me weren’t a insignificant minority, the performance gains would be fairly minimal, perhaps not even noticeable, thus the pain:gain ratio wouldn’t be worth it.

Again, I’m no expert, but I’ve wondered this myself and I sort of doubt it would make a difference in Dorico. I have almost the same configuration as wonner has (though s/he may have a higher-end GPU; I went for the lowest-spec option) … every model of that machine comes with dual-GPUs, and I’ve never seen anything worse than ~40% and 15% utilization of the pair (processor; memory usage (cache?) was something like 75% and 10%). (I’ve heard some nightmare stories of GPU code degrading realtime audio processing, and some people (usually on Windows from what I can tell) saw an improvement when changing to lower-spec’d GPUs that had different code which didn’t steal from the DAW. But unless someone from the team chimes in to say otherwise, I’d really doubt GPU would make any difference in Dorico note-input/engraving.)

Marc, one thing you haven’t mentioned which may or may not be relevant: are you running any virtual instrument plugins or are you working in silence? If you’re running virtual instruments, hosting them outside Dorico results in performance gains for a lot of people. If relevant to your workflow, some hosts offer free 30-day demos you could evaluate. If you ended up purchasing, it could cost quite a bit less than upgrading hardware.

#20

The Mac I referenced in the reply above has dual AMD FirePro GPU cards, so I don’t think that is an issue.