Re: Fixes issue 786, "Extenders in lyrics stop prematurely if a single underscore is found."

[csnyder]

On 2009/11/10 20:00:00, joeneeman wrote:
> http://codereview.appspot.com/150067/diff/2003/3005#newcode113
> lily/extender-engraver.cc:113: if (!melisma_busy (voice) &&
> !current_lyric_is_skip_ && lyric_acknowledged_)
> Could you please add a sentence or two explaining why this test is
here?

> Also, please add a comment explaining (at a high level) why we need to
pass
> empty lyrics to the hyphen and extender engravers.

I'll try to explain both of these together. Here are the cases I'm
addressing:

1) "La __ _ _ la la" (issue 786)
Extender followed by manual melismata (worked before commit 7531ea6b3,
broken after)

2) Same as above, but with an additional voice with a different rhythm
(issue 800)
(worked before 7531ea6b3, broken after)

3) "La -- _ _ la la" (worked both before and after 7531ea6b3, but needed
to be addressed while fixing 786)

4) "La __" with music continuing after the end of the lyrics (broken in
some cases before 7531ea6b3, fixed after)

Pre-7531ea6b3, extenders were only finished at either (a) the next
lyrics in the block or (b) the end of the associated voice. This led to
problems when the voice continued without additional lyrics (a situation
I encountered a couple of times when engraving vocal music with multiple
verses and a single refrain, alternate texts, etc.).

7531ea6b3, my previous commit, added a check in
Extender_engraver::stop_translation_timestep to check if the associated
voice was in a melisma, and to completize the extender if not. This
fixed case 4, but broke 1 and 2. The reason is, the extender-engraver
had no way of knowing whether the lack of additional lyrics was due to
reaching the end of the lyrics block or because there were manual
melismata (underscores). By changing the lyrics-engraver to not kill
LyricsText objects caused by manual melismata, the extender-engraver is
now able to tell the difference between the two cases and react
accordingly.

The empty LyricsText objects introduced a problem with hyphens, however,
since the hyphen's right bound would attach to the empty LyricsText
object instead of the next non-empty LyricsText, necessitating some
changes to the hyphen-engraver to accomodate this.

Regarding issue 800 (case 2 above): I'm starting to second-guess my
solution to that. In fact, I might have even completely un-done the fix
from my earlier commit. I think the problem is that melisma_busy only
works if the current timestep coincides with a note in that voice. It
seems to me that melisma_busy should be modified to return true in this
case.

http://codereview.appspot.com/150067