Dorico does of course try to prioritise input from the user. (What else is it going to do?!)
But it is the case that in large projects, the impact of inputting even a single note can be significant, and indeed that as projects get larger and larger, the likelihood grows that inputting a single note will have a significant impact.
Every edit you make in Dorico causes it to run its entire layout processing stack. This is split into three phases (pre-spacing, spacing, and post-spacing). Each phase contains dozens of distinct steps. Many of these steps are carried out in parallel (typically either allocating a single staff, or a single instrument to its own thread), using multiple cores, but the process as a whole cannot be completely parallel, because at the end of each phase, all of the answers from each thread need to be reconciled before the next phase begins.
Doricoâs architecture is heavyweight, without question. Performance relies on Dorico processing the smallest possible span of music in response to each edit.
However, at a bare minimum, even in galley view, Dorico needs to recalculate the accidental state, which typically affects a minimum of two bars (the current bar, and the previous bar; if youâre unlucky, it will also affect future bars, if for example the note you are inputting is longer than the current bar). It may add or remove accidentals at multiple positions. The music in that region at a minimum will be respaced.
The span that needs to be processed can often be much longer than just two bars, however, if there are long slurs, or long groups of dynamics, or long cues, or other types of regions (bar number regions, slash regions, bar repeats, etc.). If you end up with a pathological case where many such long items overlap a little, the range can be extended significantly.
Even when you are inputting into a single instrument, because the music has to be respaced, every instrument has to be reprocessed. Every instrument therefore has the opportunity to contribute to the overall range that needs to be reprocessed.
There is significant complexity, therefore, in the way Dorico works out what music to reprocess in response to an edit. Certainly we have had bugs in this area of the program that result in much larger ranges being reprocessed than they should. We would need to see your specific score and have some specific steps (e.g. which layout, which flow, which bar, which instrument, what duration of note are you adding) to be able to say with certainty what is actually happening in your case.
It is certainly true that Dorico is much slower with large projects than we want it to be. With our small team, it is a constant challenge to determine what we should be working on at any given moment. There are no quick wins, no simple things we can do to radically change the performance profile of the software. It is likely that it would require multiple months of work from the majority of the team to make real headway in this area. There is significant risk that we could expend all that time and not manage to deliver significant improvement, and in the process introduce new bugs.
And during the time we spend working on performance, we cannot be working on other things, so the opportunity cost is significant. Users are impatiently waiting for improvements of all kinds. Performance is a feature, absolutely, but it has to compete for priority with every other functional improvement we want to deliver.
I know this is not what anybody working on large-scale projects in Dorico wants to hear, and believe me, I donât particularly enjoy writing it. But this is the reality.
As a practical next step, give me the information I need to look into the specifics of your current project, and we can at least try to identify whether there is something unusual going on.
