Autoplace fails to avoid melisma underscores

Working on it

It's simple enough to do autoplace for lyricsline (hyphens and melisma), just call autoPlaceSpannerSegment() at the end of LyricsLineSegment::layout(). Unfortunately, any adjustment made here won't be reflected in the alignment of the lyrics themselves, which happens in Score::layoutLyrics(). We will probably need a two-pass approach akin to what I did for articulations and slurs, but I think at that point we should also consider how to allow for manual adjustment of individual lyrics as well, as per #283796: Manual adjustment of vertical offset for lyrics not possible.

So getting this right is a bigger change than I was hoping for, and I'm passing on it for now.

I am not sure this is related issue and so not sure I should open a new issue for following problem. I searched forum for this problem but didn't come up with anything, though I suspect I just missed it. I doubt this is a new thing. I apologize in advance. If you know of the issue and it is dealt with elsewhere, please advise.

I created a lead sheet with lyrics for several verses of a song. I had the piano solo turn-around measures at the end then realized I wanted it as the intro as well. My solution is to simply insert 3 measures at beginning of score and cut/paste piano intro to beginning. However, when I did that all the lyrics had the underscore lines running through them.
----My Workaround was finally to copy the song/Lyric measures and paste them in added measures after piano solo turnaround. Then delete all the measures up to the piano solo, thereby accomplishing the task without inserting measures before lyrics. Seems like I should be able to insert measures before measures with lyrics without messing things up.

I have included the file in question and also the workaround whereby the first 3 measures were originally the last measures. Moving the verses after these final measures worked.

It's not the same as this issue, but might be the same as #282099: melisma underscore going backwards in multi-voice context. No multiple vocies involved but I don't know that it was conclusively shown that was the issue in the other score, either.

Workaround is just delete the first lyric then add it back. If you can give precise step by step instructions on how we can reproduce this problem starting from a good score, that would be great - but I'd recommend doing so in that other issue.

Never mind, I see it happens any time you insert measures, and is not related to that other issue. I'll submit a new bug report myself.

See #285304: Insert measure in front of lyric with melisma extends line through following syllables

https://musescore.org/en/node/290434 has screenshots

Indeed.

1. Open attached score (produced in 2.3.2).

Result: Melisma collides with either stems (if there's no slur) or slurs.

Using MuseScore 3.2.3 - Mac 10.11.6.

The melisma can also collide with notes (or at least some other elements - such as stave text) on other entries (see this).

Indeed, melisma is not considered at all. I did look at what would be involved to support it, but there are multiple dependencies that complicate this. I agree it would be worth the effort for someone so inclined.

Perhaps, rather than strict bounding boxes around each lyric, there should be a region of exclusion at lyric height across the entire system.

Bounding boxes

Exclusion zone

I suppose this might create problems if people start shifting individual lyrics around. Possible solutions could make the zone...

• Extend from the top of the highest shifted lyric to the bottom of the lowest one.
• Measure-based rather than system-based
• Lyric-based (like a bounding box) but it extends all the way to the next lyric (or to the next note without any lyric or lyric continuation).

Alternatively, the zone could ignore shifted lyrics, and the algorithm reverts back to using bounding boxes for those cases.

Anyway, lyric shifting is not something you see done in professional scores, so it doesn't really matter how MuseScore deals with it.

@Jojo-Schmitz, but that's the point. There is indeed space there, but should we use it? In my opinion it would be better to keep lyrics clear of other symbols, especially ones that belong to other parts. However, I will need to check what Behind Bars has to say on the matter...

In other words, I doctored the example to raise this point specifically. In the real piece, the notes between 'mer' and 'brise' are an octave lower and the only issue is with the rit. However, I think that the problem is more general than avoiding collisions: the lyric region should not be encroached by other symbols, especially ones from other staves.

That's a tricky thing, though. In the above example, I think most people would probably be OK with the notes in the 2nd staff being allowed to overlap the area between "mer" and "brise" because there is a fair amount of space there. But if those syllables were closer together, the notes might be more distracting. Worse still if it were actual text on the lower staff now overlapping the space between lyrics. We already do get occasional complaints about this. I could imagine a scheme where there is a configurable amount of extra space around syllables. That would actually be pretty easy to implement, I think - a style setting specifying an amount that we add to either side of the "shape" of the lyric before adding it to the skyline. Perhaps also before calculating the distance below the staff for the lyric.

But that doesn't directly help with the melisma line & dash issue. As I recall, the order in which we do these things made it difficult to get right, and my first attempts ran into some roadblocks. That might have been before I made some changes to the calculation of lyric position to allow manual adjustment, though, maybe now it would work better.

Here's my contrived example to show why that isn't always a good thing:

The "and" here is staff text belonging to the staff below, but I don't think this would be considered acceptable layout. If might be if there was a lot more room between "one" and "two" that somehow made it more obvious the "and" this wasn't a lyric.

> @Marc Sabatella: In the above example, I think most people would probably be OK with the notes in the 2nd staff being allowed to overlap the area between "mer" and "brise"

Ah, but "Would most people be OK with this?" and "How would a professional notate this?" are two totally different questions.

Unfortunately I could not find reference to this case in Behind Bars, but I have made a post in the "Music Engraving Tips" Facebook group.

Following :-)

For what it worth, I agree that staves should not impede into the space where verses belong for the reason Marc said. There are several things that could cause confusion from the lower staff. If the user needs the staves closer together in such a case they can use the fixed distance spacer to pull the staves together. I would think this is the less commonly desired spacing so it would make sense to make this the exception. I also suspect this would be the easier fix than putting melismas and hyphens in the skyline.

To me, it's a subjective enough case that it frankly doesn't really matter to me one way or another which is the default, given that we know a spacer works around it if you prefer the other in any given situation and it's not unlikely both cases would exist in the same score.

But, I don't think it gets us off the hook for thinking about melisma lines, because we also have to consider collisions with content above the lyrics - e.g.:

A potential problem is that we don't know how big the gap between "one" and "three" will be until we've finished laying out the system, stretching measures, etc. But most of lyrics layout is after stretch, so we might be OK.

I guess I wan't clear. If the verse were a no touch zone regardless of if there is a melisma or hyphen as Shoogle suggested it would take care of both cases.

> @Marc Sabatella: most of lyrics layout is after stretch, so we might be OK.

It would have to be, because lyrics are kept at the same height all the way across the line: you don't know how far down to shift any of the lyrics until you know how far down to shift all the lyrics. First you need to know how many measures will fit on the system, in case the last measure has a very low note, etc.

Anyway, that's the existing algorithm. As far as a new algorithm is concerned, the exclusion zone seems the simplest method, but if people are not happy with this then a possible solution is to go back to using bounding boxes, but to extend the bounding box as far as the next note or rest in the lyrics line. If the next note or rest has a hyphen or melisma then the box is extended again.

This method deals with lyrics being moved around by the user, but it assumes that you are happy to allow encroachment in places where the vocal lines has rests. This might be appropriate if there are lots of rests (i.e. between "hand" and "into" in this example), but it is probably not appropriate if the rests don't actually take up much room (like between "into" and "your"). That could be solved by saying, if the region of rests is less than some width (e.g. 20 sp.) then the bounding box is to be extended through that region.

However, tight bounding boxes would still be needed to work out how closely the lyrics themselves can be packed, and therefore how closely the notes can be spaced (similar to stretch). So getting lyrics right requires at least 2 passes:

• 1st pass: calculate the width of each lyric syllable and space notes accordingly until you fill the system.
• 2nd pass: go back and move all the lyrics down until there are no collisions.

It's not until the 2nd pass that you will be aware of the distance between lyrics, but fortunately you don't start moving them down until that point anyway, so it is safe to say that you have all the information you need.

I’d like to speak out for lyrics being an exclusion zone. I’ve allowed slurs to come close to melisma lines, but only with a little distance from the line, not cutting it like in chen lung’s example. In general, it must be visually clear that lyrics belong to the stave above(for voice 2)/below and not the other one, and lyrics MUST be vertically aligned the same throughout the entire “line” (stave, but not score), so Marc’s contrived example is also out.

There are melisma-lyric collisions in the attached score: measures 6 and 8.

High priority fix with no action in 11 months?

See also https://github.com/musescore/MuseScore/pull/6081, which was my fix for #304353: Melisma Collides With Next Words/Syllables in Lyrics. This changes some things about how lyrics layout is done, in a way that could potentially allow for a solution here too someday. But it's a tough problem to solve without more fundamental changes to how layout of melisma lines is performed.

Relates to #311175: [EPIC] Engraving issues and suggestions

Partially, anyhow. The change made will prevent collisions from staff to staff, not not within the same staff. So cases like https://musescore.org/en/node/280139#comment-935593 will still be off.

Automatically closed -- issue fixed for 2 weeks with no activity.