Manual score redraw option for performance
On large scores, edits can start to take quite a while, especially if the score is split into linked parts. This almost becomes a deal-breaker as the score reaches a certain size. However, I'm wondering if this can be solved to a large extent without much programming effort, and I wanted to see if the developers think this is possible.
Would a manual redraw option be easily feasible (i.e., disabling automatic redrawing of the entire score for edits)? This seems especially suited for edits that don't currently affect layout (v2), such as moving a slur or a dynamic marking. This takes a painfully long time on large scores with individual part sheets. What if we simply redraw that particular element (temporarily)? I don't mind of temporary "gaps" or white-outs are left in other elements in the score, until the manual re-draw command is issued. That would be similar to the way older diagramming applications worked, where if you moved an item it would simply leave gaps where it used to be until the re-draw command was pressed. If possible, I think it would make polishing up scores much faster. I have noticed that sometimes, almost randomly, moving a particular element (like a dynamic marking) suddenly becomes super-fast--so somehow I think the entire score re-draw is somehow sporadically bypassed.
Also, for entering notes on large scores, I wouldn't mind if other staves didn't look right for a while in this "manual redraw only" mode. Other staves could have measures that are too long or short temporarily, or just look terrible, and I wouldn't mind--so long as I can enter notes quickly and efficiently in the staff that I care about at that moment. And then when I issue the manual redraw command, MuseScore can do its entire re-draw calculation.
Does this sound like something that may work? I have downloaded the source code, but I'm using Visual Studio 2017 and the compile instructions aren't quite ready in the development docs yet (though it looks like it's getting close). Anyway, thanks for all your work--I really like the flexibility and overall functionality of MuseScore.
コメント
The redrawing algorithm in version 3.0 is being redone and is promised to be much faster. I haven't tested it so I don't know how much faster. I have the same slowing down experience you do in large scores or scores with parts.
For 3.0, the idea is that only the portions of the score that need to be redrawn will be. In many cases, it might be just one measure, or one system, or one page. So yes, it will be much faster unless you happen to be changing something that does affect the entire score (eg, changing the staff size).
In reply to For 3.0, the idea is that… by Marc Sabatella
Great, thanks for that update. Do you think it's worth me looking into some sort of "manual redraw" feature for v2 in the meantime? Or would it perhaps be better to wait for 3.0, since this is already being addressed?
In reply to Great, thanks for that… by psrankin
I think there would be too many problem associated with not laying out the score - too many interdependencies such that a change that didn't come with a layout would probably leave things in an inconsistent state as often as not. But FWIW, it's actually trivial to disable the relayout - it happens in one pretty specific place in the code, and I had played once with the idea of not laying out the parts on a change to the score and vice versa. But this only bought a 50% increase in speed, and it wasn't worth the risk.
In reply to I think there would be too… by Marc Sabatella
Okay--thanks for the insight. I'll wait for 3.0 then. I believe I can largely work around this issue if I finish the master score first (not worried about precise layout/formatting for individual parts), then create parts and export them to separate MuseScore files, and then do part-specific layout clean-up in those individual files instead of doing everything in one large file with linked parts. I just have to make sure all the measure numbers, rehearsal marks, titles, and score-wide formatting is nailed down before exporting those individual parts. That method seems to be much faster for layout clean-up and should get me by until 3.0. Thanks again, and have a great day!