Some considerations regarding Continuous View
Recent discussion in other threads (see, for instance, https://musescore.org/en/comment/940716) suggest reviewing the very concept and implementation of Continuous view. In the corresponding handbook page, https://musescore.org/en/handbook/3/viewing-and-navigation, we find the following note: "Because the layout is simpler, MuseScore may perform faster in Continuous View than Page View". However, it seems to be the other way around in the current implementation.
What is continuous view intended for? Let's first comment that appart from educational and study applications, there are three main uses of MuseScore: 1) Transcribing engraved music, 2) Transcribing hand written music, 3) Composing music. In all three cases there are two stages: inputting the notes, dynamics and other symbols, and formatting the final score. For scores with very few staves per system, such as soloist music or chamber music, in which several systems fit on the page and on the screen, it may make sense to edit directly in Page view, especially in the case of engraved music. But when working on large scores such as large band and orchestral music, continuous view offers a distinct advantage: more music can be seen at a glance since no screen space is used for margins and page separation.
As in cotinuous view the page distribution cannot be seen, any attempt to format the music may be a waste of time. For that very reason, layout refinements for continuous view should be kept at a minimum and affect only the visible part or, at most, +/- one screen to facilitate scrolling.
Sometimes spacers are necessary, for instance, when the area between staves is overcrowded or when lower ledger lines from one staff collide with upper ledger lines from the next, to prevent input errors. However, they should affect only the current screen. When after scrolling a spacer goes out of the screen, its effect should disappear and replaced by the standard staff distance or by the effect of any spacer that could appear on next screen (or the maximum if more than one). The only undesirable effect would be that the vertical position of the next staff would change somewhat, but as the name of parts is shown at the left of the score window no confusion is likely.
Comments
If I understand it correctly, request is (briefly and without details ):
"Give us a Continuous-View as simple-and-basic as possible so that we can work quickly without being affected by page/format -elements".
+1
In reply to If I understand it correctly… by Ziya Mete Demircan
Yes, you are essentially right!
Thanks for your power of synthesis!
FWIW, though, a large number - probably a majority - of actual scores posted here and questions asked about continuous view are very different from what you describe. What I see mozt often is people using it for music with only 2-4 staves per system, and the reason is to avoid the visual distraction of line breaks. This is specifically what is not a concern for large orchestral scores. And then it's these people who are msot expecting that automatic placement would still function, in particular, staff spacing should reflect lyrics.
What this suggests is perhaps a different mode might be more useful for your particular use case. Although as I have tried to explain before, I seriously doubt it would actually produce any real benefit to only update the layout for the portion of the score in view as this would make scrolling have to wait for the layout to finish.
In reply to FWIW, though, a large number… by Marc Sabatella
Currently, there is a single-page-viewing option where I don't understand what it's used for, never use it and I don't need it at all..
Compared to this, the request for a "basic and simple continuous-view mode" doesn't seem unnecessary.
In fact, it seems like a basic need.
Make a light and basic-continuous-view-mode where you can enter notes with lightning speed, users will know what to prefer.
Who wouldn't want to work, with the "World's Fastest Musical Note Input (Engraving) Software"?
In reply to Currently, there is a single… by Ziya Mete Demircan
True!
In reply to FWIW, though, a large number… by Marc Sabatella
The statistics you mention might be misleading, since it refers to people willing to share their scores through the site, which If compared with the number of downloads (Wikipedia says several years ago were 7000 a day) might yield a completely different demography of users (or not, but who can tell). But what is most important: Is the MuseScore organization willing to let MuseScore gain terrain into new "market" niches? Symphony orchestras and large bands are a gigantic niche and I think the reason why it hasn't the same presence in these forums is because they are not sufficiently convinced that MuseScore could fulfill their needs to give it a try. I have some evidence from the local symphony orchestra.
Regarding the autoplacement, you are right that users may expect autoplacement to work in continuous view as well. But this is not incompatible with what I'm suggesting. Any change in staff spacing, either due to autoplacement, spacer, lyrics or whatever, could be treated the same way: locally.
Finally, scrolling only needs layout to finish for the next couple of screens. It is never so fast to overload the algorithm, but if it were, it wouldn't be worse than the current situation since scrolling very quikcly along an extended range is a far less frequent operation than adding notes, for instance. The time needed to relayout a single screen is negligible. In my example from the other thread, if the full relayout of 270 pages takes 11 s, then one page takes 0.04 s. In contrast, adding or removing a single note takes about 0.4 s (measured by adding from the piano keyboard a lot of notes as fast as I can and counting the time until the operation is complete; and then pressing rapidly the undo icon to revert). I don't know if adding a note triggers a full layout, but I do know that in a short score the delay is much more imperceptible.
In reply to The statistics you mention… by fmiyara
I don't have statistics, just a gut feel. And logic - seems obvious more people produce smaller scores than large ones, and there are likely very few people producing scores so large that they are noticeably slow even with the huge improvements we've already made. That combined with the fact that as I keep saying, i think for technical reasons what you are proposing would not actually work well, makes me question the ROI on this. But I certainly won't stand in the way of someone willing to invest that sort of time.
As for adding a single note, of course that does not trigger a full relayout - that was obviously the most important thing for partial layout to work with. If it triggered a full relayout, it would take 11 seconds like operations that trigger full layout fo (eg, style changes, and apparently adding or changing spacers).
I still say, simply optimizing that to make the partial layout even faster would produce far more benefit to more people with less effort than inventing a new mode that does things entirely differently. but again, if someone has that kind of time on their hands and wants to give it a shot, that's fine with me. Maybe they could first learn the code by implementing the things I have suggested that I know would be effective and helpful first, before embarking on this.