my score is steady growing and currently the performance has reached a point that Dorico is hardly usable.
Each entering a single note takes about 2-3s which drives me crazy, because I am normaly far ahead and when I did a mistake it takes very long until I notice it. Undo is equally slow.
My score currently consists of 13 flows with ~70 systems in Galley View and in total it has reached a size of about 50 pages, the file has a size of nearly 12MB.
I am working on a MacBook Pro from 2015 with 16GB RAM and a 512 SSD.
I probably could split it down into several files, but I am afraid that bringing it all together later introduces new problems.
What can you recommend to improve the performance - except buying a new laptop ?
In case that there is not much doable at the moment, will version 1.0.30 contain improvements in that area?
The flows, the Galley View and the rich key command sets are great concepts!
My son builds custom beasty desktop music computers, and they still struggled with Dorico scores of your size last time I tried. I think the key is patience as Dorico matures… Finale will open a similar file in seconds with no working latency even on a mediocre laptop today…
I seem to remember the claim that the original Sibelius 7 on the Acorn could reformat a Wagner opera score in a second. That must have been 20 years ago. I’m not sure the Windows and Mac versions have ever achieved that.
The original version of Sibelius didn’t apply a fraction of the number of formatting files that Dorico does, so that’s like comparing apples and oranges.
We have made a number of optimisations for large scores in 1.0.30 which hopefully will really improve things for your score. We found a number of places that were very slow when you have a large number of flows. It’ll be out any day now. If you continue to find it really slow then please send us the score and we can see if there’s a particular choice path showing up as slow in it.
A couple of things here. First I know that 1.0.30 will contain several improvements in that area. John mentioned it in his latest video cast and I did send a very large score with over 50 flows to Steinberg which they have been able to use in their test loops to improve performance. So I know from contact with them on this matter that much significant work has been done there. Whether it’s going to be enough for your file remains to be seen of course, but there’s also a great workaround.
Create a temporary score layout named “focus” and in setup mode, uncheck all the flows you are not presently working on. Use that layout to do your work one flow at the time. Restarting the program after creating and paring down that layout is sometimes necessary for the full effect, but it really makes a huge difference.
Thanks for confirming that .30 does contain speed optimizations. Looking forward to trying it with my test score. It’s a full score of some 2000 measures. It’s a single flow though, so I hope the speed improvements aren’t solely targeted at multi-flow documents.
The Acorn Sibelius did indeed feel blazingly fast, but it was also hand coded in Assembler IIRC … Never tried anything this big on it though…
many thanks for the replies!
So there is hope and I should wait for the upcoming patch release.
Regarding the comparison of Sibelius for Accorn RISC PCs and todays Dorico: I don’t totally agree that this is comparing apples with peaches. The Finn brothers, the original authors of Sibelius, developed very efficient data structures plus they did much in Assembly and they developed their own graphical user interface. That made it so extremely fast, even on a hardware that was more than 20 older.
Today the Dorico team has work on top of two different OS and they have probably to cope with layers that one would not have if one would only develop for a single platform.
But anyway it is a matter of data structures and algorithms that make an application fast. And from the users perspective, they have the right to not care all about this, but to expect an application that is capable to handle a score of a 4h opera for a romantic full orchestra on a typical todays hardware.
In the end it is from my point of view, the correct approach of the team, first to have a stable application - and Dorico is extremely stable - and then make it faster. As Herb Sutter, C++ Book Author and ISO C++ chair said once: “It is far, far easier to make a correct program fast than it is to make a fast program correct.”.
I ought to add that I spent 12 years working on Sibelius. Please take it from me, Dorico is (necessarily) doing an order of magnitude more calculation. This is not to undermine in any way Ben and J’s amazing achievements, which have laid the groundwork for all that has followed since. Rest assured that performance is always in our minds, and we are constantly looking for improvements.
Don’t get me wrong. I appreciate Dorico very much!
Otherwise I would not have jumped on the train with version 1.0.10 and started my new project with Dorico, even there are some understandable deficiencies
It would be interesting to know if anybody ever actually demonstrated that, since it would have involved entering the entire score by hand There was no MusicXML or Photoscore back then!
Of course somebody could have created a few bars and copied them 1000 times, but that isn’t necessarily a realistic test of reformatting music with hidden empty staves, etc, etc .
And some of those decisions (which of course were “a good idea at the time”) eventually turned in to “technical debt” limitations, of course - for example the limit of “only” 64 note head types (which seems plenty, till you discover how many new ones get created unnecessarily when you didn’t expect it!)
Or that fact that everything in the score spacing is fixed to a “grid” of 1/32 of a staff line space.
Or why MIDI data was fixed at 256 ticks per quarter note, which is not a good idea when you try to mix tuplets and MIDI files…
But don’t forget the Archimedes computer architecture is actually far from dead. The chips in most mobile phones etc are direct descendants of that original design. There are far more “computers” in use today with ARM CPUs than there are with Intel CPUs. If the original software was in the public domain, it might be a fun project to convert the original Archimedes version of Sib to a cellphone app!
?
Never tried anything this big on it though…