Hyphenated melisma requires too much space

It's not the same rhythm and the measure is stretched in this example. It's less bad than described.

Some context: MuseScore normally assumes each chordrest requires space to accommodate the full width of all lyric syllables attached to it. So lyric syllables never normally overlap more than one note. There is code to exempt melismas from this, so a long melisma syllable can overlap multiple notes. But it only works for melismas created by extender, not hyphenated melismas. Hopefully a simple matter to extend it.

The issue would be more noticeable with a longer syllable.

The good news - this is very simple to fix now that I've already added the code to *detect* hyphenated melismas in the first place (see #17190: Non-last lyric syllables on slurred/tied notes are centered rather than left aligned). The bad news - the simple fix would come with the same caveat as #5261: Lyrics for melismas should not respace notes if there is room before next syllable. That is, the lyric is more than happy to overlap the next note, but it's also more than happy to overlap the note after that, and the note after that, and if long enough, the syllable will run into the next lyric syllable.

So in the following example, it's great that "looooooong" is able to overlap the first three notes in both cases, because the next syllable doesn't come in until the fifth note:

But had the word actually needed to cover only the first two notes, we'd be out of luck:

And fixing this - basically spreading out the necessary extra space over all the notes up until the next syllable - is *not* trivial. I should it's basically the same thing that is done for chord symbols, but chord symbols are a simpler case because there aren't multiple verses, and in any, the chord symbol code isn't without its issues as well that are even harder to solve (eg, what happens across a barline).

I have a notion that perhaps instead of automatically kicking in every time there is a melisma, this could be made a checkbox item in Inspector, kind of like the "Local Relayout" for beams. And if you enabled it for any given lyric syllable, it would be up to you to add measure stretch or segment extra leading space as necessary to avoid collisions.

Or, we could wait until "someday" when we start doing more of this sort of automatic collision avoidance.

Still looking at this, because the situation right now is not so good - end-of-word melismas (with extenders) can overlap notes but might collie with the next lyric; middle-of-word melismas (with hyphens) will not overlap notes at all. Neither situation is great, but the inconsistency is perhaps even worse.

I have it working so that by default, we get the current hyphen behavior - too much space, but no collisions - for both hyphens and extenders. But if you give the magic command, you can force a melisma syllable to overlap subsequent notes. You risk collision, but since you are going out of your way to ask for this, hopefully you'll also be prepared to deal with the fallout by adding stretch or leading space as necessary.

Right now, the "magic command" to exclude a lyric syllable from spacing is ending a syllable with a space (entered via Ctrl+Space). I suppose it could be an Inspector option, but given that it still isn't that great, I'm hesitant to expose it that way. Which makes me question whether it's worth doing it all, of course.

But BTW, I also made it so the same "magic" command will work with *non-melisma* syllables to ignore the *leading* space. This allows it to fix #22696: Lyrics don't overlap stave elements, although with the same caveat - there will be nothing preventing your lyric from extending left into the left margin and indeed spill off the page if it's long enough.

Here's my code:

https://github.com/musescore/MuseScore/pull/1330

Ctr+Space seems an odd choice of shortcuts since it is already used for adding space to a lyric syllable. Is it because you are trying to avoid adding something to the MuseScore file format?

I guess I could go either way: either add the manual option now or wait to add a fully automatic option later. If we add the manual option i suspect it is safer to document it in the file format and handbook than to have unexpected behavior for everyone except the readers of this bug report. (And some of us who do read the bug report may forget about it a few years later).

Yes, I am trying to avoid adding new to the format, also trying to avoid actually adding any new Inspector options to support a questionable feature. I am not using Ctrl+Space as a new shortcut - I am using it for its normal function of adding a space to the end of the syllable. The space doesn't affect layout, but it gives me something I can check for. Gives us a way of testing the functionality without requiring either file format or GUI changes.

But I guess my main question is this: am I right in feeling it's better to avoid collision by default, even if it means unnecessary space is allocated?

should be fixed since ab15653

No, this particular behavior was not changed, because there was no way to address the collision issue described in comment #4.

It has been over five years now, and I'm running into this problem again. Has there been any work towards providing a workaround for this? I am not able to find a more recent thread, nor am I able to use control space as indicated in this thread. I don't want to make a new thread, but this is becoming a nuisance with sixteenth note melismas to have the first sixteenth note take up three times the space of its partners.

Can you explain the issue you are having in more detail? Ideally by attaching a sample score? For me this is fixed in 3.0:

Let's mark it fixed then

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