Melisma line over system break

I'm going to bump this as it is still relevant as of 1.1. One could arguably say this is a feature request and not a bug report, as there is probably some precedent for not continuing underscores on the next system (I think that might be the default behavior in Sibelius?) but it's definitely not the way most published music I see is done.

See also http://musescore.org/en/node/15806

And http://musescore.org/de/node/16540, includes a score showing the problem

Also reported on the Dutch forum at http://musescore.org/nl/node/18443

I could reproduce this problem with MuseScore 1.2 and the nightly build, with the score attached to http://musescore.org/nl/node/18431#comment-67111 (made with .2).

See also this screencast: http://www.screenr.com/vWw8

as a substitute type [SPACE] as lyric to the first note of the second system

Guess you meant Ctrl-Space?

oh yes. Actually CTRL SPACE is the way to type a SPACE in lyrics.

Brilliant! thanks for coming up with such a simple solution.

First time I tried it (based on the suggestions earlier) nothing happened and I wondered what I was missing. Now I see - you enter ctrl-space as the lyric for the first of note the new system *and* then type an underscore. But as far as I can tell, it works only if the *next* note also needs an extender. Otherwise, I still get no extender under the first note of the new system.

Well,
If the first note of the second system is the last of the melisma you are expected to end the line just right short of this note, Just use one (or 2) long underscore

(under 2.0 at least)

Yes, that's what I've been doing as a workaround. But it doesn't quite look right visually. This really just needs to be fixed.

Just came up again in http://musescore.org/en/node/23860

I'll add my voice to those requesting a fix for this... it's definitely confusing. The Ctrl+Space workaround does work fine, but I'm not following how to use the solution in post #11 above when the first note of the system is the last note of the melisma. When I try to enter an underscore, it just moves (as expected) to the next note.

I'm curious why has this bug has been open for over 4 years and has not been fixed? I'm using version 1.3 which is the current public release and I'm assuming by aTallCuyNH that the nightly build is non-functional too?

The solution of CTRL-SPACE does not work if you are needing continuation on the first note of the new system and only that note. If the next note picks up a new syllable or word then there is no way to extend the Melisma in to the next system.

What is the priority in fixing bugs like this that has been open for over four years? I would think it would be assigned to someone to fix since there have been a number of other bug posts over the years and probably because of this bug post others have refrained from adding more? Are there any technical reasons why it cannot be fixed? Perhaps if we better understand why this bug has not been addressed then it will be easier to deal with it's short comings.

Don't get me wrong, I love musescore but this is one of the few "bugs" that I cannot work around.

One visual hack is to use the plain line (not really sure the correct name) which is found in the "line" pallet at the bottom. But I am not sure what it will actually do to the score and the playback. I would expect that it would interfere with it. Is there any way to draw a line in musescore that will not have an impact upon anything?

I should also add a comment that there is also a problem where the Melisma will not display on the very last note of the score. It will only extend to the second last note.

Hi
"it would be assigned to someone to fix". It doesn't work like this. Bugs are fixed by people on a voluntary basis. They are not assigned to someone.

I don't know all the ins and outs but I can see how this bug is technically challenging. In particular, relayouting a score and changing line breaks would possibly delete, multiply or divide this additional melisma mark(s). Also, what should happen is one of these lines is moved, the other should move too? The main one?

Like any open source project, the bugs that get fixed are the ones that bother someone who knows how to fix them. So far, this hasn't, apparently. It could be some don't consider this a bug - certain other programs don't do this continuation either, or make it optional.

Meanwhile, as a workaround, the line should be perfectly safe. The only downside aside from being more work is that it won't necessarily keep its relative position as well if the score layout changes, and if the line break goes away, you'll need to remove the line break manually. A better workaround might be simply typing underscores (Ctrl+_), although these too will need manual positioning.

BTW, the melisma on the last note *does* display in the end, but it doesn't right away after entering it. It reappears the next time anything happens to force a re-layout (on any edit, etc).

Marc,

Can you explain the Ctrl+_ solution in detail? I have never been able to get this to work. So far I've just gotten used to this limitation, but it is confusing from a readability standpoint, so it would be great to have a workaround.

No special magic. If you need more than just one continuation note, use the Ctrl+Space trick, which works great (for better results, hit the right arrow before entering the space, so the extender begins right under the first note). If you need the extender on just a single note, simply enter a couple of underscores as the actual lyric for that note. You can type an underscore by as Ctrl+_ (otherwise, of course, simply typing the underscore causes it to be interpreted as a lyric extender). Doesn't work so hot if it's a long whole note, I guess, because you'd need a whole bunch of underscores as the lyric, and this would affect note spacing noticeably. So then you're probably better off drawing the line. That's always harmless and effective.

Lasconic and Marc: Thanks greatly for your quick replies!

You both have made some great points and with being a simple user it is easy to forget that it is open source. :) You both have done a great job of touching upon some of the challenges that would make this difficult to fix. It just appears that on the surface that when two measures are side-by-side it does work as expected, but when the second measure gets wrapped to a new system then that is when the problems surface.

At this point in time I'm using the ctrl-underline technique since at least it is a lyric. The line does look good too.

Thanks again for the feedback.

This issue seems to have become even worse, following some recent changeds: now the melisma line not only is missing in the next measure, it also shows up in reverse direction in the starting one, if the word is suffiently long to go over the barline:

Could you please post a sample score and steps to reproduce? I recently made a change that *prevented* backwards melisma lines that otherwise could have happened, but it's possible some specific case was broken as a result. I trill don't see melisma lines continued to the next system at all - and indeed, there is no code to handle that. So I suspect you are talking about something unrelated. So probably best to open a new issue.

BTW, I did look at the original issue here while working on lyrics code recently. There is a placeholder in the code to handle this case - also melismas that span more than two systems, so there are one or more systems containing nothing but one long extender. It's not implemented because the place where we realize we will want the melisma line is while processing the syllable itself on the first system, but unfortunately, we cannot really lay out the extender on the next system at that time because the system itself has not been laid out yet. So instead we'd need to record somewhere that we will need the extender when we do get around to laying out that system, and do it in such a way that it cleans up after itself if the system layout changes (eg, number of line breaks change).

I think I can see a way to do this, but I also know Miwarre was at one time working on something that might be usable here, so I didn't spend much time trying to get my method working. It's not off my radar, though.

I've email you a score (copyright restrictions...)

Update: actually, I can reproduce the problem in #22 if I *don't* try to extend the melisma over the system break but between two measures on the *same* system. So definitely not related to the current issue, and not particularly new, either - it's in the beta, and probably dates back a couple of years at least. This is actually fixed by the change I mentioned above - I had forgotten that that PR hadn't been merged yet. But FWIW, in conjunction with that fix, we would be backing out the code that allows lyrics to extend over barlines in the first place, since there is risk of collision with lyrics on subsequent notes if the syllable is long enough.

Still worth filing the issue, to make sure that whatever we decide regarding whether lyrics will be allowed to overlap other notes / barlines, we include my fix to prevent backwards extenders.

should be fixed now, c69d2a9

Miwarre re-implemented melisma lines in 405074a. This should now be working correctly as of the latest nightly builds. Testing encouraged!

It is indeed working, quite well I might add (and I've been long awaiting this feature)!

However, there are complications that arise when making them unselectable and unsaved. Namely, since lyrics often collide with the notes above it, I manually reposition them by adding some vertical offset to each lyric in the system. This causes the melisma to have that offset as well, including the melisma in the next system, which will likely require a different vertical offset.

I have added a feature request for this: http://musescore.org/en/node/44421

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