Melisma Collides With Next Words/Syllables in Lyrics

Note: in the example above, if you replace "small" and "prob" with just a single "s" or "p", there is no issue. As you type letters into those syllables, you can see what is happening - we're adding more space, but clearly not the right amount. I suspect we are trying to avoid a collision with the preceding syllable itself but are getting the calculation wrong.

Well, no, 2.3.2 has far worse issues with layout that are much harder to work around. These cases don’t come up that often or we’d hav tons more reports of it. You can just increase stretch in the affected measures as needed.

Yes, again, I understand am that in this particular unusual situation, layout might be slightly worse. But I. 99% of other cases, it is better - much better. There were hundreds of improvements to layout, many specifically involving lyrics, because 2.3.2 was quite bad at them, often overlapping lyrics or adding way too much space or otherwise doing very bad things that were very difficult to workaround. Overall, there is absolutely no way 2.3.2 would be doing better in general. This particular measure might look better, but most would look far worse, and be harder to fix. I encourage to do further comparisons with other measures and other scores to fully appreciate just how much better MuseScore 3 is in laying out lyrics despite this one small regression.

Indeed, which means it's only a melisma followed by a non-melisma, and only in fairly crowded scores.

Meanwhile, in MuseScore 2, those same crowded scores would generally have hyphens disappearing, syllables bumping up against each other, and - worst - melismas often forcing a ton of extra space before the next note rather than replacing the notes evenly. Plus all the things autoplace buys that makes the default layout in 3 so much better.

Marc, I think that the problem is made worse by the fact that a melisma end takes no account of the setting of "Melisma pad". See the example below, where the melisma pad is respected at the start of the melisma - but completely ignored at the end of the melisma. This causes a collision with the following lyric, and to my mind this is a major fault which renders the score unsuitable for publication.

The attached example score is taken from a song in the OpenScore Lieder Corpus, where I have reviewed many scores which display this same melisma problem. It would be great to have it fixed.

Agreed, this isn't minor. As mentioned, MuseScore has even more serious issues with layout, but this deserves to be looked at for MuseScore 3.

A concern is that fixing it may result in some measures becoming wider and thus altering the layout people are expecting.

FWIW, the "pad" is only supposed to affect the space before the melisma line. The space after should be controlled more by min note distance and lyrics min distance (although the latter is ineffectual in practice because it is measure to the previous lyric, not the melisma line itself, it seems - see below).

I guess the thing we will need to discover is, what percentage of scores will be helped versus hurt. You say it's any score with a melisma that has the problem, but that's not really true - it's only scores that are especially dense. Scores in which the measures are spaced more widely are not affected at all. I think that is why there have only been a small handful of reports of this in the past year and a half, so it appeared to be a rare/isolated problem. In any case, for whatever reason, it hasn't looked serious enough for anyone to really sit down and really identify the cause until now.

The question is whether the fix will end up causing all scores with lyrics to take more space. That will depend of course on exactly where the issue is and how it is fixed. As far as I can tell on initial investigation, the issue is not with the calculation of the length of the melisma line or with the calculation of space before/after it. I believe the issue is that, in the cases where the next lyric is centered, we are not correctly accounting for the melisma at all. We are dutifully allocating enough extra space to avoid colliding with the previous lyric (which you can see if you continue lengthening the syllables, but we are failing to account for the melisma.

So for example:

In the first version, the centered lyric is short, and there is no problem. In the second, it's long enough to overlap the melisma, because we really are ignoring the melisma. But in the third example, where the centered syllable is very long, you can see we do add enough space to avoid colliding with the first lyric.

So, the code that added space for the third example needs to be adjusted to also add it in the second example, I think. The trick will be to distribute that extra space well so it doesn't look unnatural - this was one of the serious problem with MuseScore 2 (and 1 before it) that is fixed in MuseScore 3. See for example this image from the original bug report, comparing the old MuseScore layout with LilyPond; MuseScore 3 now closely approximates the latter:

An interesting workaround I'd like people to try, even though I recognize it's not anything resembling a real solution, even temporarily:

Any time you see this happen, click the note under which the melisma line ends - the last note you previously hit underscore for. Press Ctrl+L to enter a new lyric there, and enter Ctrl+Space around four times (probably depends on font). This shouldn't really work, as entering that lyric should really go back and shorten the melisma, but somehow it does what I want, so let's go with it for now.

The effect will be to create a "visible" (but not really, since it's just space) barrier at the end of the melisma line for the autoplace algorithm to then try to avoid. That's needed for now because the melisma line itself is invisible to autoplace.

Although this is, again, not something we want people to do, what I'm interesting in is if you are OK with the results. In contrived cases, it's going to be bad, but it's OK in normal cases, and I'm not sure what the alternative is. Here's an example of my concern:

Maybe there is a better way to space this, but I'm not sure what it is. The desired result, though, will determine how any solution gets implemented.

Of course in real life, syllables aren't that long, and there would likely be another syllable on the next note, so it's more like this:

which isn't so bad (aside from the lyrics themselves, of course :-)

"An interesting workaround I'd like people to try..."
Marc, thank you for the idea. But I don't have a record of all the previous scores in the Lieder Corpus where I have been tripped up with this melisma problem. And on principle I don't like using kludges or workarounds: I prefer just to leave the notation "as is" until the problem is finally fixed in the code.

Off-topic: another example is the fact that tuplet brackets cannot be set horizontal using "Maximum slope = 0.00" - it is just broken. See issue: #294098: Tuplets need a "Set bracket horizontal" checkbox in the Inspector. So instead of manually tweaking dozens of tuplet brackets, I just leave them looking ugly until the bug is fixed. It's not pure laziness: it is simply a case of "not enough hours in the day"...

Yes, I understand this is not remotely practical for real world usage. But I need some people to at least give it a try and give me their feedback on whether the results work well for them, or if you see cases where the spacing is still as bad as, for instance, it was in MuseScore 2 in the example I showed above. If people feel the results are acceptable, then we can begin considering implementing an algorithm in the code that produces similar results. But if people find the actual results not good, and can give better suggestions, then we can investigate other possibilities. The point being, in the open source world, we rely on the users who report issues to help us understand the issue and the possible solutions. Since this issue doesn't affect me personally, and I don't have the extensive experience with the types of scores that are affected as you do, I can't really begin to consider implementing a solution until someone helps me evaluate the results produced by my workaround.

Regarding the tuplet issue, feel free to follow up there. In order to help prioritize this, it would help to have some insight into why you find completely horizontal tuplets to be so important to your work. There are, as you say, only so many hours in a day, and we need to prioritize things. So it really helps us when people who report an issue give enough context for us to better understand that the issue may be less rare or less minor than it first appears.

Marc,
You said "But I need some people to at least give it a try and give me their feedback on whether the results work well for them, or if you see cases where the spacing is still as bad as, for instance, it was in MuseScore 2 in the example I showed above."
Understood, and I will do some tests around this suggestion.

Regarding the tuplet issue, I have posted an image which illustrates the problem:
https://musescore.org/en/node/294098#comment-996394

From MuseScore 2

Marc,
I also tested your "add 4 spaces" solution, and for my example your advice works quite well.

@etienne "I would consider a "better" fix to simply make the melisma shorter, even removing it entirely for very small spaces."
I like this idea!

[EDIT]
@Jojo-Schmitz "No, not shorter. Just end exactly at the ending note's right edge. And move the next lyrics' start a tiny bit further right, like the setting of melisma pad, so it applies left and right"
And Jojo's idea on 2nd May sums it up even better...

I think the melisma should never ever 'overshoot' the (last) notehead, but stop at it's right edge and get omitted entirely if it otherwise would.
Although this alone wouldn't fully solve this issue unfortunately

That too is a pretty contrived example, though. Indeed it can not look good in some cases, but I’m interested in how it might work in real world cases. Especially if you can compare results to MuseScore 2 (which I think would have produced similar or worse results in that contrived case).

Not overshooting the notehead is certainly an option but it buys only a tiny bit of space, doesn’t really change the overall spacing. And I don’t think you really want it any shorter than that, certainly (?) you don’t want the next centered lyrics overlapping the last note of the melisma as that would be misleading.

No, not shorter. Just end exactly at the ending note's right edge. And move the next lyrics' start a tiny bit further right, like the setting of melisma pad, so it applies left and right

Oh, I agree. I was responding to the idea that making the melisma shorter would somehow fix the actual problem. It won't address it all. Check the examples posted - the places where the centered syllable overlaps the previous melisma, it also overlaps the previous note. This is, I would assume, completely unacceptable. So shortening the melisma doesn't solve the actual problem at all. One way or another, there needs to be more space added. It's just a question of exactly how/where it is added.

For example, consider my second example above in https://musescore.org/en/node/304353#comment-996322 (the one where the problematic lyric is "abcdef". Leaving the spacing alone but shorterning the melisma to avoid the collision actually makes it worse. At least now there is some clue that the syllable "abcdef" comes right on beat 2. Shorten the melisma to avoid the collision and now it appears to anyone reading this that the syllable "abcdef" comes on the last sixteenth of beat 1.

The only solution is to increase spacing in some way so that syllable is still centered under the correct note and there is enough space before the note so that it doesn't overlap the previous note. The only question is what effect this should have on the spacing of other notes. Is it acceptable to just increase the space before that one note, or should the spacing of all the intervening notes be increased as well? The latter might produce a more balanced look but definitely worsens the issue of additional space being added.

So in particular, I'm comparing proposed solution A:

with proposed solution B:

To me there is no doubt solution B looks nicer, but the effect of the Ctrl+space workaround is to produce A. But while I can see possible ways of implementing something that would produce A automatically, it's harder to see how to get B automatically (I did it here only by adjusting chord offsets manually).

For the record, MuseScore 2 produced something that is worse than A or B, although of course better than overlap :

Here we see the uneven spacing on the first "oooo" as well as both before and after the "abcdef". That's because of the same problem I mentioned earlier, luckily fixed in MuseScore 3.

So the question is, would A at least be a decent compromise for real world scores? It's clearly way better what either MuseScore 2 or 3 currently do, but if there were a lot of real world scores that had both spacing as tight as this and a lot of six-letter syllables in this position, we'd see that awkward gap a lot. In the real world, maybe that happens seldom enough to not care.

Regression from 0.9.5!

After encountering the same problem, i found this thread.

Marc, your solution with the spaces works for my case here. See the attached files

Thanks for the feedback!

So the solution I envision would have us automatically create the equivalent of that space below the last syllable of a melisma. It wouldn't be an actual lyric you can select or edit, just an invisible barrier below the last syllable of the melisma that autoplace knows not to bump in to. Again, the reason we need to resort to tricks like that is that at the point where we are trying to avoid collisions between lyrics, we haven't yet calculated the length of the melisma line - it's kind of a chicken and egg problem. Previous versions did things the other way around, and that's why we had that other bug where syllables couldn't overlap the next note at all.

It's still tricky to actually implement, but I think it will be a workable approach.

I have a trial implementation, the code is pretty "hacky" right now but I can clean it up if we are happy with the results. Could people please post a few actual score examples? The ones attached so far all work well enough, but most of the examples here are just pictures, I really need actual scores.

One thing I haven't done yet: shorten the melisma line. I see where in the code we decide to overshoot the note (by the "Min note distance" setting from Format / Style / Measure). I am not really sure why it's doing this, but apparently it was that way in 2.3.2 as well. FWIW, due to a typo a couple of years ago, though, we actually don't overshoot the last note any more for melisma lines that continue across systems.

Does anyone have any insight into why we might deliberately overshoot the last note, though? I don't see Gould doing this.

BTW, I also found a curious bug (and hence a potential fix for) where the end point of the melisma line can be wrong if either the start or end note of the melisma is part of a chord with seconds (and hence includes notes on the wrong side of the stem. We sometimes use the width of the start chord instead of the end chord to decide where the melisma end.

Here is a PR: https://github.com/musescore/MuseScore/pull/6081

I have marked it "work in progress" because I still need to clean up the code. But first I want to do more testing, and hopefully get help in this. See below for "artifacts" you can install yourself like a nightly build and test:

Windows: https://ci.appveyor.com/api/buildjobs/0p9speaccoj463ss/artifacts/MuseSc…
Linux: https://github.com/musescore/MuseScore/suites/676587462/artifacts/61819…
macOS: https://github.com/musescore/MuseScore/suites/676587462/artifacts/61819…

Something I know may be non-optimal is handling of multiple verses, especially if the verses have melisma in different places. Also it may not work as expected if the melisma crosses voices. But even in these cases, it should usually be better than before.

Present in MuseScore 3.5 alpha.

Of course

No longer "work in progress", I have updated the PR and am happy with it now. Here are updated builds for testing purposes:

Windows: https://ci.appveyor.com/api/buildjobs/bn17xvfdo6t2087k/artifacts/MuseSc…
Linux: https://github.com/musescore/MuseScore/suites/683227836/artifacts/63349…
macOS: https://github.com/musescore/MuseScore/suites/683227836/artifacts/63349…

I know this will mean some measures may become wider and thus change layout, but that's what fixing the bug entails. Hoepfully it doesn't disrupt things too badly.

Downloaded the updated build and looks great over here. Good work! Do you still want files to test for yourself or are you happy as it stands now?

Also, i have encountered some other quirks/bugs/things i would like to see different with regards to lyrics notation. I hope you don't mind i'm taking the liberty here to point you towards those, maybe those are not that hard to fix now that you've com fresh out of the code for lyrics notation.

Feature request/quirk regarding very short melisma's https://musescore.org/en/node/305306
Feature request regarding lyrics notation under tied notes over barline: https://musescore.org/en/node/305569
Bug, not honoring mindistance when not displaying dash: https://musescore.org/en/node/294255 https://musescore.org/en/node/294244

I hope I'm not way off base doing this, if so please just say so, i'm not trying to tell you what to prioritize, just the things i encounter regularly when using this fantastic piece of software you guys have build

I'm happy, and now that I've provided updated builds, I expect people with an interest in this topic can test for themselves. I do hope they do so, though - this could potentially have a larger than expected effect on layout of lyrics in general and I think it's important that people who run into this a lot help us test and verify the overall effect is positive.

Meanwhile, I've commented on the other threads you mentioned, thanks for the feedback!

See also #305594: Minimum melisma length

Fixed in branch 3.x, commit 9bb5f0ce52

_fix #304353: melisma line overlaps next syllable | collect_artifacts

Resolves: https://musescore.org/en/node/304353

Melisma lines are spanners and therefore not laid out until
well after note spacing and measure widths have been settled.
This means there is no way for the melisma line to influence spacing.
And yet, it needs to, if we want to avoid potential collisions.

Because we cannot use the melisma line itself to affect spacing,
this code borrows the approach used for lyrics themselves:
calling addHorizontalSpacing() to reserve space for the melisma line
when calculating the shape of the ChordRest.

In order to do this, we need to know if a ChordRestr ends a melisma.
So I have added a helper function, isMelismaEnd(), to check this.
I also fixed a couple of issues in the calculation
of the length of the melisma line.
One was that we used the width of the start rather than end note
(in cases where the next note also has a lyric, which is common).
Another is that we were deliberately overshooting
the right edge of the end note,
whereas Gould says to end at the note._

Fixed in branch 3.x, commit d0003b19a3

_Merge pull request #6081 from MarcSabatella/304353-melisma-overlap

fix #304353: melisma line overlaps next syllable | collect_artifacts_

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