Hi all.
I second Werner's opinion that the goal should not necessarily be an
identical score, but a reasonable one. This time, we could even hope for
improvements: there will be some valid extenders that users simply did
not bother (or did not know how) to add, and I think convert-ly should
not try to hide them.
On 2016-12-15 23:41, Knut Petersen wrote:
Am 15.12.2016 um 19:29 schrieb Werner LEMBERG:
We have convert-ly exactly for such changes.
I doubt that all corner cases like the Issue 1006 update given in
lyrextest.ly can be handled automatically ...
???
s/LyricExtender.minimum-length/LyricExtender.whatever-you-want/
Yes, that would be easy.
I also second Werner's though that minimum-length is not the best
description. In the context of spanners, it means "widen the score such
that this spanner has length at least x"; quite different from the new
meaning "suppress below length x" (remember that extenders never
influence spacing).
However, I dislike both minimum-space (it's not about widening so that
there is enough space, either; plus this term is already used with a
different meaning) and show-length (which sounds like a debug option
that prints or annotates the length).
What about hide-below-length or hide-if-shorter-than?
What I meant is that I do believe that it is impossible to
mechanically translate an old score to give exactly the same result
with the new code. Let's try to start.
See above; I don't think this was Werner's point.
We do not need "__", so eliminate it: sed -e "s/__//g"
Not sure if we should do that. Any __ in the lyrics don't do harm, and
it keeps the source somewhat backwards compatible.
Ok, that looks good. But wait: There is a melisma,
Which convert-ly is unable to detect, unless there are _ in the lyrics.
Other than that, melismata detection requires full parsing and
interpretation, which is beyond the scope (and intention) of convert-ly.
[...] Is convert.ly intelligent enough to handle that problem
correctly? I doubt that although I admit that I never had a look at
the code.
AFAICS, it's a slighly more fancy grep. Pure pattern substitution. So I
share your doubts.
There is one way we could stay compatible: Keep the old code and use it for
every score with a \version < X , enable the new code for \version >= X.
My KISS proposal:
(1) Keep lyrics sourcecode as-is in general (don't remove __),
(2) replace LyricExtender.minimum-length by
LyricExtender.whatever-it-will-be, and
(3) replace all 'pattern _ ' by 'pattern "" ' where pattern != _ or __.
The latter rule will miss out opportunities to create some forgotten
extenders for manual melismata, but it is crucial to leave non-trivial
divisi lyrics in a reasonable shape (see my mails from 2016-12-14 2:39pm
and 2016-12-15 1:04am UTC+1).
Gute Nacht!
Alexander
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
