Re: music function to be included somewhere in scm/*

[Alexander Kobel]

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