[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Kobel
Subject: Re: music function to be included somewhere in scm/*
Date: Fri, 16 Dec 2016 02:09:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

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 can be handled automatically ...


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 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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]