Space is not made for multiple verses in continuous view

• Sep 13, 2018 - 16:03
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
Yes
Workaround
Yes
Project

lyric spacing.PNG

As shown in the picture, when entering lyrics in continuous view, there is no space made for adding more than one verse. The picture is from an actual score, but testing a new score with default values had similar results.


Comments

Type Graphical (UI) Functional
Priority P1 - High
Regression No
Workaround No

Seems none of the things that should spaced staves work in continuous view - eg, notes way above/below the staff will overlap the previous/next staff as well. I guess it's an open question as to whether continuous view should force staves to be as far apart as they need to be on their widest system - occasional overlaps might be OK - but lyrics seems like they should be handled. That much at least worked in 2.x

Priority P1 - High P2 - Medium
Severity S4 - Minor S2 - Critical
Workaround No Yes
Frequency Many
Reproducibility Always

This was an intention to turn off autoplacement in continuous view. It improves performance and still is suitable for note input. Enabling autoplacement in continuous requires more work to interpret one loooong system correctly.

So, this is the issue, indeed, bit not the priority.

PS. Workaround for this particular issue is to manually adjust the distance between the staves.

Priority P2 - Medium P1 - High

Reported also in #280071: V3 Beta problem with continuous vs page view. Worth thinking about possible solutions. We don't turn off autoplace completely - elements still do their normal collision avoidance, I guess just the part about staff spacing is not done. What if this were done just for the measures currently in view? Could be disconcerting to see staff spacing change as you scroll. Another possibility is to simply add some fixed amount of extra space below staves with lyrics so it's not a problem as often.

I had a thought - since Shift+drag no longer works as a synonym for "Extra distance above staff: anyhow (by design), what if we instead made that action have that effect only in continuous view? So it would take effect score-wide, but you could easily pull staves closer together in sections where they don't need to be as far apart as they do in other places (and vice versa). I generally don't like actions that are mouse only, or ones I can't control more precisely (eg, via an actual numeric setting), but since this is only about the current view and not really a score setting per se that would affect page layout and thus doens't need precise control, I could live with it. We could always a separate field to staff properties for this too I guess.

@Marc, Perhaps making the shift+drag a staff affect only continuous view would be a good way to allow the user to easily adjust the space. For the most part, I expect that this space will be consistent throughout the song, but could be easily adjusted if needed with your suggestion.

@toffle, it looks like Marc is working on ideas to fix this. Feel free to suggest other options. I am only one user and welcome other opinions. A related discussion is happening at #279117: Cannot add custom lines spacers to custom palette

Right now I'm thinking three things, and I can't decide whether to do all three or just a subset:

1) change the default to be more like 2.3.2, where even one measure that requires extra space forces extra space by default throughout the score
2) implement spacers that work in continuous view only
3) allow Shift+drag to add/remove extra space

All three could work together. For 1), I would want to see if the performance hit is too noticeable. I think 2) and 3) work together nicely in that the actual effect of Shift+drag could be to change the height of the first continuous-only spacer found, or add one to the first measure if not. That way there is a "paper trail" and you can be sure of getting back to the default by removing the spacer.

In reply to by Marc Sabatella

If you make Marc's May 24th proposed adjustments in spacing to the Continuous view, what will happen to the lyric-stave spacing when the user returns to Page View or Single Page?
Am I correct that this problem affects only MS2 files imported to MS3, but does not affect files created in MS3?
It is now July, and there seems to be no progress on implementing what MS2 did so naturally: maintain the same spacing of lyrics and staves in both Page View and Continuous View.
When may we hope for MS3 to behave accordingly?
-Tom

In reply to by Marc Sabatella

I ask because spacing changes in one view typically propagate to the other views as well.

I posted essentially a related thread last night, not knowing this one was still active after so many months: https://musescore.com/groups/59271/discuss/5044248. However my issue was not about multiple verses, the title of this thread, but about single verses being mis-spaced in files imported from MS2 into MS3, which I originally posted back in January: https://musescore.org/en/node/282579.

Attached is my test file that illustrates the problem I reported in January, and again last night.

Should my 5044248 post remain its own thread or are the issues one and the same with the above post?

Attachment Size
Test of MS3 Lyric Bug.mscz 17.42 KB

Continuous view is continuous view regardless of if the score was created in version 2 or 3, so I don't think there should be any special considerations for imported scores in continuous view beyond ensuring manual adjustments are properly accounted for according to the option selected when the score is opened.

Marc's goal on May 24th was to have a special set of spacing permitted to affect continuous view only, and everything he says is that these adjustments would be retained if the user went from continuous to page and back to continuous view with no effect on page view. For those of us who prefer continuous view, I think this would be a good way to do things.

MS 2 added a set space between staves that affected continuous and page view the same, except in page view there was only space for 4 verses if there were 4 verses in the system. This was almost the full extent of auto avoidance in version 2. I wouldn't object to version 3 doing basically the same thing. Just make room for the verses and let the user worry about anything else.

There will often be a different distance between staves due to other things, but the distance between lyrics and the staves should be determined by the system settings in continuous view with no other auto avoidance). This was basically the original request.

That works for me.
What is the reason that MS2 files, like the one I attached, end up looking so bad in MS3's Continuous View, and not on Page View or Single Page?

If you mean Test of MS3 Lyric Bug.mscz from earlier today, then I only see a version 3 score. To truly understand I would need to see the version 2 score and know what option (y/n) you selected on import. At first glance I would say the main problem is the 4.5 spacing between staves.

And that should be fixed already if you reimport, 3.1 and later adjusts the lyrics bottom distance to make more sense. If that doesn't help, please start a new thread in the Suppot forum here on musescore.org so we can understand and assist better.

As for the actual issue at hand, unfortunately there is no way for MsueScore 3 to go back to the "dumb" algorithm of MuseScore 2, allocating space for lyrics but nothing else. Now that other markings are part of the skyline too, it's all or nothing. Which is probably fine. I did look at implementing this, it's doable, but slows things down for sure.

Severity S2 - Critical S5 - Suggestion

Those are sufficient if those are the only scores you are having problems with, I will respond there.

Meanwhile, let's keep this thread focused on the suggestions of ways to improve spacing in continuous view.

tomfeledy, I have looked at your file in versions 2 and 3. You are correct that there is no space being made for lyrics at all. In version 2, you have the staff distance set to 4.5 with 2 spaces above the lyrics and 4 spaces below the lyrics and these settings seem (from looking at them) to be honored and sufficient space is placed between the staves in continuous view to allow for this minimal spacing.

I realize you are not complaining about this, but I'll point out that items like the tie in bass line are getting rather close to the lyrics above and would actually overlap those lyrics if you made the note an F above that. Also if you put text above any of the singers, it would almost touch the lyrics above. These, I realize, are acceptable intrusions into the other staves.

Version 3 totally ignores the minimum distances between staves including lyric margins in continuous mode and I think that is the real issue. I believe that taking these settings into account would probably be the easiest way to fix the overcrowding in continuous mode. It would be very acceptable to me and I expect far easier than creating special spacers for continuous view only.

On import, the lyric margins are totally ignored no matter which option you choose when importing a version 2 score and I consider that a bug. Choosing "no" should take these margins into consideration. I do realize there is not an exact 1 to 1 relation between every page setting, but it would not be too difficult to compare those that affect (grand) staff distances and apply them to imported scores when "no" is selected.

The reason we stopped trying to interpret the margins is that they mean vastly different things between 2 & 3. In 2, you needed to set the margins artificially high to work around the lack of automatic placement. But now those same margins end up creating far too much space, and we got countless complaints about that, so we fixed it to reset that. I tried for a while to come up with an algorithm that could guess at a setting that might approximate the old behavior, but it's simply not possible given the fact that spacing is no longer fixed even without considering lyrics. In the end, it's just going to be expected that you might need to adjust the spacing in some cases if the new defaults are not to your satisfaction.

As for the spacers, I realize it's not ideal, but as I said, I was not happy with the performance impact of actually honoring the skyline. It's possible the is some clever way to get around this, though. One would be to not actually use the skyline normally but to simply calculate the min and max values. It will result in too much space being allocated in some cases, but maybe that's better. Another potential thing to try is calculate the full spacing only when first switching to continuous view and then only the portion that changed on a given update. The problem is, all these data structures are organized by system.

In reply to by Marc Sabatella

Perhaps I am mistaken, but it does not appear there is any agreement on what steps, if any, will be taken to resolve the problem MS3 has displaying MS2 score lyrics in Continuous View.
Until this problem is addressed in MS3, what do you suggest users to do with their MS2 scores to get their lyrics show properly in all Views of MS3?
After all, I have a hundred or more MS2 scores that I'd like to import to MS3 so I can stop using MS2 for good.
What do you suggest I do with all my MS2 scores so MS3 users can see the lyrics properly in all views?

For continuous view, the only complaint ever concerning lyrics is that they end up being written inside the staves below. There needs to be enough space for them between staves. You've done a lot to make page view much better and that's appreciated by all who benefit from it.

Marc, you're trying to over-complicate things. In continuous view if you look at the lyrics height, the top margin, the bottom margin and whatever the space between verses is (I couldn't find a setting) and add those together. If they're greater than the distance between the staves, use that space between the staves, if it's less use the min staff distance. I believe there is a road map that tells how many verses are used, so you can make that the consistent space between staves. There are places this will be too much, like in the refrain, but we can make a reasonable argument for users to understand why this is the way it is. There is currently no logical explanation I would attempt to give a user.

This will make Continuous view usable as a tool if someone wants to follow along in a song and not have the sudden page turn of page view. For a vocal score, this is next to impossible at the moment without the user being forced to insert a system spacer they don't want in page view. There is also not a bunch of recalculating distances to slow down continuous view. A one time calculation every time you draw the screen wont slow things down too much.

As to what to do with version 2 scores? Keep them in version 2. That's always been my best answer and I stick by it. Versions 1, 2 & 3 can coexist peacefully next to each other, there's no need to "upgrade" a score.

Hmm, you may be on to something, but I'm afraid it's still not that simple. We could certainly get a generic value for the height of one lyric line, multiply it by the number of verses, and add the margins. However, this would a) not recognize that the generic height might not be accurate depending on font and whether the lyric contains extra-large characters (like Ä), b) not account for manual adjustments, and most importantly, c) not account for the fact that the lyrics themselves may be lower than the top margin indicates, because the whole line of lyrics is moved down if one note is below the staff. So while this sounds nice, I just can't see how it could work reliably.

In 2.x we actually did a whole extra calculation to figure out the distance needed for lyrics, but that's gone now, replaced by the skyline calculation. We don't need all of that calculation, but since the lyrics themselves are correctly honoring the skyline (in most cases, anyhow - it's possible to perform edits in an order where the lyrics will overlap the notes they are attached to until the next full relayout, which is probably a new regression with my changes to 3.1), we could make a pass through the lyrics just looking for the lowest one.

If we do that, it is tempting to just search the skyline itself and find the lowest point, lyric or not, so this benefits instrumental scores as wel, which is what I proposed just above. Unfortunately, it doesn't work unless we actually build the whole skyline, and thus give up some of the performance wins of 3.1.

Still, like I said, you may be onto something. There may well be a cheap way to get a good approximation of the space required for lyrics alone. I'm continuing to think about this.

BTW, I said I wasn't comfortable with the amount of performance we give up to actually do the skyline correctly in continuous view. It's possible I can improve on this further, but meanwhile, anyone on Windows who wants to test my initial attempt at this (from a month or so ago), give this a shot:

https://ci.appveyor.com/api/buildjobs/oj4eyionaaldctwf/artifacts/MuseSc…

As far as I recall this build works just fine, but it's noticeably slower than the current builds. Not as bad as before 3.1, but to me, bad enough. On the other hand, maybe others will consider it a fair tradeoff.

Yes, as discussed throughout this thread, the issuenis simply MuseScore 3 does not choose to.add additional space between staves when in continuous view, period. So not just lyrics but any elements far above or below a staff can choose with the next. And the reason, as explained, is that we want continuous view to be fast, and figuring out how to add that space slows things down.

The assumption has been that continuous view is primarily used for efficiency during note input, so speed is more important that prettiness, and all that really matters is the final result in page view. And that they can always use spacers to add space while they are working and remove them when finally done.

So now we're trying to figure out alternative approaches that will allow people to use continuous view in other ways without needing spacers, or at least without needing to remove them when switching to page view.