I’ve just been adding/removing some players and instruments that are in my project. There’s always an “annoying” delay after clicking OK/delete while the computer processes what I assume is the vertical spacing.
This leads me to ask a probably silly question: is it really necessary for all the pages in a Layout to be available to view and therefore need to be processed? I feel, much like Print mode, that this isn’t necessary and that I only ever care to view the first page of the Layout I’m looking at.
Would this speed things up significantly? Does anyone else ever need to view eg the last page of a Layout whilst in Setup mode?
If you’ve got 60 flows in a project and you can’t remember whether it’s the 59th or the 60th you want to include in whichever layout, then yes, you might need to see the last page, and you might not want to switch away from Setup mode.
(This is a real life scenario I’ve found myself in, albeit thankfully not this year.)
I’m currently working on a piece that has lots of little Flows, just 3 or 10 bars each. There’s several on each page. I’m looking in Galley View in Setup mode, to work out which Flow is which, because they are all just “Flow 18”. I need to make sure I delete/duplicate the right one!
I sometimes use Setup mode as a way to navigate between Flows. Select the Flow, and the display jumps to it.
It’s a nice idea, to possibly move some layout calculations to background processing, but I know it is not the Dorico way. (And it was not the Sibelius way either.) In the early days of Finale (1989) I spent one-third to one-half of my time waiting for the screen to redraw. At my request (and no doubt many others) they managed to allow screen drawing to be interrupted by user input in many cases.
But processors are many orders of magnitude faster now, and background threading is (afaik) a whole different approach that might not be feasible in the Qt environment. (I’m talking beyond my knowledge here, so I’ll stop.)
Sorry to say, Mark, but you probably should have stopped before you even started. Dorico is fully multi-threaded. It’s designed into the architecture of the application from the bottom up.
Wrong terminology, sorry. But the important thing to me is that you don’t leave things like layout to be calculated later, or on-demand. That is correct, yes?
Having the screen display information that is ‘out of date’, while still allowing you to make edits is a recipe for error.
It’s not clear whether you think this is a good thing, or not. Finale is perhaps unique in still having the option to suspend “Automatic Layout Update”, so that changes you make DON’T get reflected in the displayed score. There’s also a manual “Update Layout” and even a “Redraw Screen” command.
I’d submit that both of those are necessities from a bygone era. Nowadays, we are much more expectant of instant results; though I too remember waiting minutes for Finale to redraw, and for Photoshop to run plug-ins, and for PostScript to be compiled for printing.
Even if Dorico takes some time to process things, then the way for the devs to deal with it is optimizing the algorithms, not implementing manual supervision.
I can see where you are coming from, but there are times, like when setting up a new project, where I know that I will do many time-consuming operations in succession, where the displayed layout is not important at all. I will add players, rearrange them, duplicate layouts, all this basic stuff where some sort of “please wait with updating until I’m finished” might be a more viable - and less frustrating - option.
From a UI perspective it might be easier to do this initial shuffling around in a popup window, so the layouting process starts when I have done my part and klick “Apply”?