#4509 Enhancement: automatically engrave lyric extenders

[Anonymous]

Originally created by: *anonymous

Originally created by: simon.al...@mail.de

Actually, this is a content vs. presentation issue. The current approach has lyric extenders ‘hardcoded’ within the lyricmode input, whereas often it depends on layout whether I want an extender printed or not:
– In tight horizontal spacing, we might not need an extender, but when spacing is stretched, it might become necessary. This can come through different (page/line) breaking, parallel contexts present only in some editions (part vs. score), Completion_heads_engraver (mensural without barlines/transcription with barlines).
– Long syllables might not need an extender, where short syllables do.
– Often, all voices share the same text, but have extenders in different places. If extenders need not be given explicitly, the lyricmode input code can be reused much easier.

After all, the extenders don’t add any additional meaning, but only serve to improve legibility in such cases where they do.

This would require:
– Recognising the end of a word by absence of a hyphen.
– Comparing printed length of the melisma notes vs. the syllable, likely after line breaking. After all, extenders will never influence horizontal spacing. They might, however, affect vertical spacing. (unless we chose to omit (or shift) the extender in that case?)
– Personally, I think very short extenders shouldn’t be printed. There should be some kind of threshold.
It’s also one of the usecases where a proper representation of a ‘lyric word’ would be helpful, along with issue 2458.

Possibly related:
issue 4098

Version 2.12 had this listed as a Known issue.

https://codereview.appspot.com/313240043 )

[Knut Petersen]

@David: We all know that you were a valuable member of the lilypond community for a long time. You were missed, and we are glad that you are back in the pond although we wished you the best for the job you tried. So don't feel too bad for jumping in late.

Currently I have little time as I need to debug my car. Some slack joint or cable break hidden somewhere deep inside the wiring loom or the electronics of the automated gear shift ;-(

Only a few comments: Detecting grace notes by the font size is an ugly hack. I did not know how to detect grace notes in a clean way. Everybody is invited to improve that portion of the code.

Your proposed patch has one problem not found in the original patch: It also adds extenders in addition to hyphens. So we probably also need to listen to LyricHyphen events here.

Also listen_lyric_event() needs to be listen_lyric() for current master.

Attached is a file I use as a test source.

[David Kastrup]

"Knut Petersen" knupero@users.sf.net writes:

@David: We all know that you were a valuable member of the lilypond
community for a long time. You were missed, and we are glad that you
are back in the pond although we wished you the best for the job you
tried. So don't feel too bad for jumping in late.

Currently I have little time as I need to debug my car. Some slack
joint or cable break hidden somewhere deep inside the wiring loom or
the electronics of the automated gear shift ;-(

Only a few comments: Detecting grace notes by the font size is an ugly
hack. I did not know how to detect grace notes in a clean
way. Everybody is invited to improve that portion of the code.

Look at the grace part of its moment? I think music columns have a
property "when" or so recording it.

So look at the grace time component of note->get_column ()->get_property
("when") or so?

Your proposed patch has one problem not found in the original patch:
It also adds extenders in addition to hyphens. So we probably also
need to listen to LyricHyphen events here.

Ah yes, of course. And of course I only sketched the changes in
extender-engraver.cc and not yet in lyric-extender.cc and the latter
will likely render some of the former nonsensical.

Also listen_lyric_event() needs to be listen_lyric() for current
master.

Ouch. I think I am currently at the limit of my concentration and need
to go into bed. Coughing and hurting all over.

I'll try to get back to it later today.

--
David Kastrup

[David Kastrup]

Folks, sorry I just can't focus right now: I have 38.7C temperature (101.7F) and there is not really much I manage beyond sleeping and coughing. Since I started yesterday with that, I expect this will likely be similar for most of tomorrow and then hopefully at least my brain should no longer be being fried.

[Knut Petersen]

This is a new version of the autoextender patch, based on current master. Documentation unchanged.

There is a new boolean property no-auto-extenders. If set true it only allows forced extenders.
The double-underscore Extender token is revived and generates a forced extender. The result should be identical to the old behaviour.

If no-auto-extenders is true, extenders are automatically generated. Extender tokens are interpreted as forced extenders.

Have a look at the code whenever you feel better.

TODO: documentation, better grace note detection

[David Kastrup]

"Knut Petersen" knupero@users.sf.net writes:

This is a new version of the autoextender patch, based on current
master. Documentation unchanged.

There is a new boolean property no-auto-extenders. If set true it only
allows forced extenders.
The double-underscore Extender token is revived and generates a forced
extender. The result should be identical to the old behaviour.

If no-auto-extenders is true, extenders are automatically
generated. Extender tokens are interpreted as forced extenders.

Have a look at the code whenever you feel better.

Thanks for pitching in here. I just went through the mail for the day
and I am afraid that I need to get back to bed right now as I am really
in lousy shape (sinuses hurting like anything and I am not even stuffed
up all that much). Let's hope that I am in better shape tomorrow.

--
David Kastrup

[David Kastrup]

"David Kastrup" dakas@users.sf.net writes:

"Knut Petersen" knupero@users.sf.net writes:

This is a new version of the autoextender patch, based on current
master. Documentation unchanged.

There is a new boolean property no-auto-extenders. If set true it only
allows forced extenders.
The double-underscore Extender token is revived and generates a forced
extender. The result should be identical to the old behaviour.

If no-auto-extenders is true, extenders are automatically
generated. Extender tokens are interpreted as forced extenders.

Have a look at the code whenever you feel better.

Thanks for pitching in here. I just went through the mail for the day
and I am afraid that I need to get back to bed right now as I am really
in lousy shape (sinuses hurting like anything and I am not even stuffed
up all that much). Let's hope that I am in better shape tomorrow.

Ah, but one thing I thought I should mention: it occured to me if we
made minimum-width obey its standard-behavior known from elsewhere (ok,
elsewhere one needs to set some spacing-rods property in addition but
probably noone will notice), we would require no forced-width in
addition.

And the particular use case of Trevor, namely setting it to zero, should
work out just the same as before, shouldn't it?

--
David Kastrup

[Knut Petersen]

Ah, but one thing I thought I should mention: it occured to me if we
made minimum-width obey its standard-behavior known from elsewhere (ok,
elsewhere one needs to set some spacing-rods property in addition but
probably noone will notice), we would require no forced-width in
addition.

Implementing a proper minimum width would help to solve some old issues ... but I think I remember someone called it a feature ... I have to think about the topic.

And the particular use case of Trevor, namely setting it to zero, should
work out just the same as before, shouldn't it?

Probably yes. If both modes are implemented better compatibility to the old mode should be implemented.

Have to leave for a rehearsal now.

Knut

[David Kastrup]

"Knut Petersen" knupero@users.sf.net writes:

Ah, but one thing I thought I should mention: it occured to me if we
made minimum-width obey its standard-behavior known from elsewhere (ok,
elsewhere one needs to set some spacing-rods property in addition but
probably noone will notice), we would require no forced-width in
addition.

Implementing a proper minimum width would help to solve some old
issues ... but I think I remember someone called it a feature ... I
have to think about the topic.

And the particular use case of Trevor, namely setting it to zero, should
work out just the same as before, shouldn't it?

Probably yes.

Well, except where the results would be an ugly flyspeck. Those would
likely fall under collapse-width. Sounds more like a feature than a
problem to me.

--
David Kastrup

[Alexander Kobel]

[...] if we made minimum-width obey its standard-behavior known from elsewhere [...]
[...] Implementing a proper minimum width would help to solve some old issues ... [...]

You are talking about a minimum-width that affects the horizontal spacing? I can't immediately see great benefits from it, but also no shortcomings. I agree that minimum-width = #0 combined with collapse-width > 0 should satisfy most requirements.

forced-width on its own could still be nice to have if extenders must be shortened to less than the natural available length, e.g. for shortened extenders before repeat alternatives. (Just in case this can "easily" augmented with a to-barline setting, I toss that coin in the pool again...)

[David Kastrup]

"Alexander Kobel" akobel@users.sf.net writes:

[...] if we made minimum-width obey its standard-behavior known from
elsewhere [...]
[...] Implementing a proper minimum width would help to solve some
old issues ... [...]

You are talking about a minimum-width that affects the horizontal
spacing? I can't immediately see great benefits from it, but also no
shortcomings. I agree that minimum-width = #0 combined with
collapse-width > 0 should satisfy most requirements.

Sorry, still out of commission. Today was the first day where the
temperature dipped for half a degree temporarily but I'm still basically
knocked out. Fourth day in a row: way more than I am used to.

Back in bed in a few minutes, sorry for not keeping up with the mess I
stir.

--
David Kastrup

[David Kastrup]

This appears to be written on top of the existing patches, so it would make sense to put it on Rietveld on the existing review (which I have no write access to). It needs rebasing to current master because of issue 1375. Here would be the rebased patch (minus the whitespace error).

[David Kastrup]

Alexander? You appear to own the Rietveld issue. Could you add this patch?

[Alexander Kobel]

Sorry for being late to the party. Will do, albeit probably not before the evening.

[Alexander Kobel]

Done it earlier, but missed the right git-cl config, hence no notification auto-generated here. Anyway, it's live at Rietveld now.

[Anonymous]

Unless I am mistaken, this is still a bit aways from pushing. I shall therefore gently tug this one back to Review for now.

Of course if one is mistaken,wel, Developer's perogative and all that.

[Anonymous]

Setting back to needs work - please see David Kastrup's reply above re: reapplying a diff.

[Knut Petersen]

Commit 67f386e3d8e235361e5b81d6789f2c402a59521f broke the patch, so here is an adapted version.