Sense of auto placement in continuous view: question for MuseScore gurus. ( Who said "Marc" ;-) ? )
Hi,
From https://musescore.org/en/node/280890 "Insanely slow score editing on Musescore 3" it appears that MuseScore spends lot of time doing layout in Continuous view.
But I wonder ... in continuous view, width of measure is not constraint by page width.
So all auto layout working is done on measure width that will change once one switches to page view.
And doing manual fine adjustment to auto layout in continuous view is losing your time as that must be (potentially) done again in page view.
So I wonder, should MuseScore do any "complex" auto layout at all in continuous view?
Couldn't we consider continuous view as a music entry mode in which the layout is not perfect but data entry is instantaneous, including for huge scores ?
Switching to page view would trigger the auto layout algorithm (switch to "engrave mode" to copy Dorico terminology).
Or perhaps auto layout should be limited to current measure only in continuous view, to keep readability of the current measure but ignore potential collisions in other measures, making it a very fast operation?
Should fine manual adjustments be allowed at all in continuous view, considering that once in page view they could all need to be redone?
Could we at minimum offer an option to turn auto layout off in continuous view (everything is just set at default position) to get a very fast input mode, auto layout would start again in page view ?
... ?
Comments
My impression is that we don't do as much autoplacement in continuous view - that's why lyrics can collide with the staff below, for instance. I kind of doubt the autoplacement is the main slowdown here - I suspect its more about the basic default placement before autoplace kicks in.
I do share your sense that it might be a good idea to disable some manual adjustments in continuous view as there is a good chance they won't make sense in page view - but on the other hand, some such adjustments do make sense either way. Probably the most we should do is consider using the "tours" facility to warn you.
In reply to My impression is that we don… by Marc Sabatella
Hi Marc,
Thanks for your response.
You say:
<< we don't do as much autoplacement in continuous view - I suspect its more about the basic default placement before autoplace kicks in. >>
Then there is really something very strange and possibly a deep design flaw to fix in MuseScore.
How can simply assigning a element to its default position be so slow for big scores?
How is it possible that it depends of score size at all?
In reply to Hi Marc, Thanks for your… by frfancha
It's no "flaw", and it's no different than 2.3.2 or indeed 1.0. The reason that layout speed depends on score size is that can't just recalculate the position of the one element you moved, we have to recalculate everything potentially affected by that change, and up until 3.0, we really didn't have any way to determine that so we always did a full layout of the entire score on every change. After all, even changing one note could make a measure slightly wider which pushes the subsequent measures on that system to the right, so they all need to be recalculated. And that might in turn push the last measure of the system to the next system, which then requires it to be recalculated, etc.
In theory, one of the advantages of 3.0 is that we can try to detect how much needs to be recalculated and only do that much. But even if the algorithm decides "great, we only need to recalculate the current system", that doesn't help in Continuous view, because the current system is always the whole score. And in any event, it sounds like the algorithm isn't working as intended any, as Eric is saying it that even in Page view, the debugger is showing that each page is actually recalculated.
In reply to It's no "flaw", and it's no… by Marc Sabatella
<< The reason that layout speed depends on score size is that can't just recalculate the position of the one element you moved, we have to recalculate everything potentially affected by that change >>
Then we come back to my original question: why would we want to do that at all in continuous view ?
Why can't we just put the added/updated element on the score without recalculating anything? (in continuous view only of course, page view would still recompute everything necessary (but not more hopefully))
In reply to << The reason that layout… by frfancha
The same reason we do in page view. Even a one note change might mean the adjacent notes need to move (e.g., consider changing G to G#, thus adding an accidental and thus pushing everything to the right), and the measure might get wider meaning the adjacent measures might need to move, etc. Otherwise you would end up with notes overlapping each other. This is absolutely no different between Page and Continuous views; it's just easier to say in Page view where this can stop - the first system that has no changes at all. In Continuous view, some programmer with enough time on their hands could implement something to stop at the first measure that is completely off-screen, and then also make sure every scroll operation also does the necessary layout calculations - something that currently is not needed, so it's probably a fairly significant change.
In reply to The same reason we do in… by Marc Sabatella
I don't see any reason to do all this relayout work further than the current mesure in continuous view.
That would have the major avantage to get (almost) instaneous updates in continuous view, including for huge scores.
In reply to I don't see any reason to do… by frfancha
As I have explained above, the reason is that any change can affect the width of the measure and thus create overlaps into the next measure, and so on down the line, potentially to the end of the score.
In reply to As I have explained above,… by Marc Sabatella
The widths of all measures in continuous view is fixed unless you change something in that measure. Since there are no page breaks to take into consideration, calculating the measure width of every measure in continuous view is a waste of time. I would prefer to have a long pause while all of the calculating is done once when I switch from continuous to page view. I understand it's necessary to do the calculations for page view because changing something in a measure may change the width of the measure and affect which page it is displayed on. This just isn't the case in continuous view.
In reply to The widths of all measures… by mike320
I fear I must not be doing a good of explaining the technical details here.
Indeed, widths of other measures are unlikely to change (they can, actually, if ties or other spanners are involved, or beams across barline, or autoplace involving text that spans the barline, or if clef or key changes are involved etc). But independently of that, the positions of subsequent measures most certainly do change. If measure 17 becomes wider because of a change within it, measure 18 must necessary move to the right or there will be overlap, and thus the same for measure 19 and so on to the end of the system (= score, for Continuous view).
It probably seems like that moving everything over to the right happens almost as is by magic or that the work involved would come for free, but this just isn't so. This is part of the layout calculation. In principle these calculations could be optimized to only redo the horizontal component and nothing else, but the algorithms just aren't structured that way, and redoing them to allow that would likely be a lot of work. could well be worth looking into. But again, I'm just trying to help people understand the issues here, not to argue that there is no possible solution to then given enough time and effort.
In reply to I fear I must not be doing a… by Marc Sabatella
Yes, measures to the right of the current measure must all be moved by the same amount of space when the current measure width is changed.
By that's just a fixed common change for all of them, and not a computation to do by measure.
In reply to Yes, measures to the right… by frfancha
Right, as I just said, it works be possible to rewrite the algorithms.to.only update the horizontal positions, doing so by a fixed amount. The algorthms just aren't written to do this currently, and it works be a fairly significant change to get right, but in principle it is totally doable given a sufficiently motivated programmer with enough time on his hands.
In reply to Right, as I just said, it… by Marc Sabatella
Or we could change the way position is stored in continuous view, to store it relative to the end of the previous measure.
That way, there would be nothing at all to update, other than the current measure.
In reply to Or we could change the way… by frfancha
Many things are already stored that way. But then you still have to update the measure positions, and fix up.the things that aren't / can't be represented relative to measures only (eg, spanners).
Once again, I am not saying this is impossible. Just trying my best to explain how things are currently and what might be involved in improving them. there is nothing being suggested here that isn't patently obvious as a call didate for potential optimization to be made in the future. It's just like anything else, a matter of a sufficiently motivated programmer to make the time to actually do it.
In reply to I fear I must not be doing a… by Marc Sabatella
You're abandoning reason, digging your heels in and insisting on the company line that there can be nothing wrong with the way the program currently works. There is no reason that a measure before the current measure in continuous view should EVER need it's width changed by doing anything to the current measure. There is practically no auto placement involved in continuous view, so the widths of the previous measures will not EVER change. If there were some auto placement involved, it would move things vertically which wouldn't affect the width of the measure. You really shouldn't need to recalculate the width of subsequent measures, but not knowing the code I can see where it might be necessary to layout visible measures, but not the entire score.
Most of what I said applies to page view also. In page view I can understand needing to relayout the previous page, but nothing before that. Nothing you do on page 4 should ever affect what's on page 2, it's layout should be fixed. Perhaps the total logic of the way the program is set up is flawed and the attempts to speed it up failed miserably.
In reply to You're abandoning reason,… by mike320
Once again, I am not saying the algorithm cannot be improved. I am simply trying to explain how it works, why this is, and what the issues would be involved in improving it. Some day I hope to see someone to undertake this effort.
Note also I said nothing about previous measures. That indeed would be a much easier optimization to perform. I have no idea if it is or not. But still in general, on average, time will depend on score length unless the layout algorithms are hanged more fundamentally, for the technical reasons that I am doing my best to explain in as non-technical language as I can.