Well, several thousand classes is really a lot.
If parallel processing does not help Dorico that much, essentially that means Dorico runs/feels faster on a dual core 3 GHz than an 8 core 2.4 GHz CPU?
And congratulations on the release (even if a bit too early).
No, not at all.
The kind of thing GPU multi-processing is good at is “take this list of 2,000,000 numbers, and multiply them all by 5”. The same operation on a large amount of data.
Totally different than CPU multi-threading, which is running many DIFFERENT operations at the game time.
I felt regretful to see people’s responses regarding their disappointments towards the UI fluency of Dorico, despite my experiences of running it fluently under macOS through low-resolution mode on non-retina displays. Good luck to everyone.
It certainly does help, but only at certain parts of the layout process. For instance if you have a score with 50 instruments, then there are some phases of the layout processing that would happily run on 50 processors in parallel if you had them, but then the next phase may need to be serial, so it’s down to one thread, but then the next phase can do 4 things at once, so you’re up to 4.
If you have more cores then you will get better performance in general, but it won’t scale linearly (ie a 16 core won’t be twice as fast as an 8 core). Playback however will be able to take more advantage of your cores.
Dorico’s advanced algorithm optimizes and redraws the score so intelligently. This intelligent algorithm though, is run for every note being changed/inserted.
Perhaps it is too demanding to be run automatically on every note change?
Maybe a button like Sibelius’ “Optimize Staff distance” is the way to go? Let us do all the actions we want without the staves being re-drawn, then, when we’re done we could press the “Redraw” button, and have this cpu demanding algorithm only run when needed?
As Paul mentioned, we have mechanisms in place to only reprocess certain ranges of data when a change occurs.
This results in a trade-off between maximum performance and the risk of not updating something that should have been updated.
We erred on the side of having the score draw correctly first before going back and optimising the performance by tweaking those ranges.
We are absolutely sure that we can make Dorico more responsive. It’s a very active topic in the office right now and there are already improvements going into the first update.
Then the score redraw should be considerably fast with a one-bar-one-staff test project. However, moving a single note up or down in a score consisting of a total of only 5 notes is still very slow. So your argument is invalid.
With other words: The redraw of a score containing 5 notes should be considerably faster than the redraw of a score containing 5,000 notes. Which is not.
Agreed. I don’t know why it’s so bad then.
We’ve fixed this particular case. It wasn’t due to the speed of redrawing the score - rather it was the refreshing of the ui that was slow
I tried out Dorico with a different monitor and got much better results. I was getting a lot of lag running it on my 4K monitor, but I tried it on a 1080p and it is MUCH more responsive. Just wanted to share here in case anyone else was running at a higher resolution monitor.
I find the program laggy as well. For example, with a tiny score created from scratch, adding a player, deleting a player, adding a flow, deleting a flow. These types of operations take 250ms to 1sec. OS X 10.11.6 on a Macbook Pro Retina Late 2013, 16GB 2.6 GHz i7.
These are all cases that we’re aware of and working to improve.
I agree it’s pretty slow, although I can live with it. However, there’s one instance when the lag seriously affects my work, and it’s when I’m writing lyrics. Dorico can’t keep up with my typing speed, and the lag makes letters disappear, so I have to go back and add them, which of course really slows down the process.
One example of this: This is me typing “Re-qui-em ae-ter-nam do-na e-is, Do-mi-ne,”
The Core 2 Duo models of mac are having pretty small VRAM available for your system, especially those major macOS releases since Mavericks.
I am afraid Steinberg needs to address the minimum hardware requirements more specifically.
I suggest such requirements for Mac computers are at least having the VRAM not less than 1.5GB (except Intel HD4000, 512MB, runs Dorico fine on my alternative hackintosh ThinkPad W530 except the computer-specific “playback not reading the tempo markings” issue).
Is your video chipset HD3000?
Please provide your information regarding the Graphic card installed on your vintage Mac Pro or Hackintosh.
There is a reason why Apple changed their 3rd-generation Haswell 15-inch MacBook Pro in mid-2015 to use AMD graphics in lieu of the NVidia one. Prior to macOS Sierra 10.12.0, the NVidia driver (written by NVidia but not Apple) shipped with macOS El Capitan for GT750m (the one used on your laptop) does not support Metal acceleration pretty well, making your graphic hardware unable to get fully accelerated under HiDPI mode. In your case, there is an effective workaround: run Dorico under low resolution mode with its resolution no more than 1680*1050.
I’m running a NVIDIA GeForce GTX 960 (2GB) on my Mac Pro (Early 2009)