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

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

2016-12-14 Thread Alexander Kobel


Hi Knut, hi all.

On 2016-12-14 10:16, Knut Petersen wrote:

Hi everybody!

There is a discussion on lilypond-user with the target to allow
automated lyric extenders to lilypond. One part of that is a patch
to clean and extend lyric_extender.cc.


Knut is playing down his work here. The crucial point: with his patch, 
there is no harm in adding lyric extenders everywhere, because they will 
not produce any output on non-melismata (unless overriden specifically). 
Also, the handling of extender's minimum-length is cleaned up.



To allow automated creation of lyric extenders a helper function is
needed


... that does exactly this, adding extenders everywhere.

IMHO, the actual question to decide upon is: Do we want this to be 
enabled by default? IIUC, the fact that extenders are not automatic is a 
known shortcoming. NR 2.1.1 states under "Known issues and warnings":
"Extender lines under melismata are not created automatically; they must 
be inserted manually with a double underscore." (see 
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable)


With Knut's patch, this will mostly impact scores where extenders are 
left out unintentionally. Still, it will be a burden for convert-ly 
unless we have a global (or per lyric definition) \noAutomaticExtender 
rule that is inserted by default.


On the other hand, there is the chance to get rid of scores where users 
don't add extenders simply because they are not aware of their 
importance or the proper syntax.




Putting the
following code into a lilypond score does the job:

#(define autoextenders (define-music-function (lyrics) (ly:music?)
   (music-map
 (lambda (event)
   (if (and (eq? (ly:music-property event 'name) 'LyricEvent)
  (not (let* ((art (ly:music-property event 'articulations))
  (is-hyphen? (lambda (ev) (eq? (ly:music-property
ev 'name) 'HyphenEvent
   (find is-hyphen? art)))
  (not (string=? (ly:music-property event 'text) " ")))
  (ly:music-set-property! event 'articulations
 (append (ly:music-property event 'articulations) (list
(make-music (quote ExtenderEvent) event )
 event)
   lyrics)))

Q1: Where should a definition of \autoextenders reside?
scm/music-functions.scm?


AFAICS: yes.


Q2: Obviously the definition of \autoextenders does not match the coding
style used in scm/*. It does not even
work if it is added to music-functions.scm. Some advice is needed ...
the extending-manual is not a real help in
this case.


I think you mixed up define-music-function and a plain Scheme define.
IIUC, define-music-function creates an anonymous function with some 
syntactic sugar (e.g., type-checking of the additional arguments past 
parser and location) which is then assigned to a variable:


function = #(define-music-function
 (parser location arg1 arg2)
 (arg1-type-check? arg2-type-check?)
 ...)

That's used in user space and relies on Lilypond's parser, for the 
assignment of the anonymous function. So if we use that, it must go to 
some .ly file with my original syntax; e.g. ly/lyrics-tkit.ly, is apt.


Otherwise, it can go to a .scm file as just
(define (autoextenders lyrics)
 (music-map ...))


Cheers,
Alexander

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2016-12-14 Thread Urs Liska



Am 14.12.2016 um 10:43 schrieb Alexander Kobel:
>> Q2: Obviously the definition of \autoextenders does not match the coding
>> style used in scm/*. It does not even
>> work if it is added to music-functions.scm. Some advice is needed ...
>> the extending-manual is not a real help in
>> this case.
>
> I think you mixed up define-music-function and a plain Scheme define.
> IIUC, define-music-function creates an anonymous function with some
> syntactic sugar (e.g., type-checking of the additional arguments past
> parser and location) which is then assigned to a variable:
>
> function = #(define-music-function
>  (parser location arg1 arg2)
>  (arg1-type-check? arg2-type-check?)
>  ...)
>
> That's used in user space and relies on Lilypond's parser, for the
> assignment of the anonymous function. So if we use that, it must go to
> some .ly file with my original syntax; e.g. ly/lyrics-tkit.ly, is apt.
>
> Otherwise, it can go to a .scm file as just
> (define (autoextenders lyrics)
>  (music-map ...))
>

Not having looked into the actual code I'd like to add that within a
.scm file you'd define a music function as in Knut's original email -
but without the starting hash sign.
But music-functions.scm doesn't seem to use this syntax and does plain
defines (or define-public).

Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2016-12-14 Thread Urs Liska



Am 14.12.2016 um 10:43 schrieb Alexander Kobel:
>> To allow automated creation of lyric extenders a helper function is
>> needed
>
> ... that does exactly this, adding extenders everywhere.
>
> IMHO, the actual question to decide upon is: Do we want this to be
> enabled by default? IIUC, the fact that extenders are not automatic is
> a known shortcoming. NR 2.1.1 states under "Known issues and warnings":
> "Extender lines under melismata are not created automatically; they
> must be inserted manually with a double underscore." (see
> http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable)
>
>
> With Knut's patch, this will mostly impact scores where extenders are
> left out unintentionally. Still, it will be a burden for convert-ly
> unless we have a global (or per lyric definition) \noAutomaticExtender
> rule that is inserted by default.
>
> On the other hand, there is the chance to get rid of scores where
> users don't add extenders simply because they are not aware of their
> importance or the proper syntax.

My gut feeling says: Yes, this is an improvement and should be there by
default. IIUC the reason why this has to be discussed is because that
could change/break existing scores, right?

If so, could you please think about an example where the patch would
have a negative impact that can't reasonably be caught by convert-ly?
Just because you two are much more into the topic, so that could help us
others understand ...

Urs
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

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

2016-12-14 Thread Alexander Kobel

Hi Urs, hi all.

On 2016-12-14 11:18, Urs Liska wrote:

Am 14.12.2016 um 10:43 schrieb Alexander Kobel:

To allow automated creation of lyric extenders a helper function is
needed

... that does exactly this, adding extenders everywhere.

IMHO, the actual question to decide upon is: Do we want this to be
enabled by default? IIUC, the fact that extenders are not automatic is
a known shortcoming. NR 2.1.1 states under "Known issues and warnings":
"Extender lines under melismata are not created automatically; they
must be inserted manually with a double underscore." (see
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-vocal-music#multiple-notes-to-one-syllable)

With Knut's patch, this will mostly impact scores where extenders are
left out unintentionally. Still, it will be a burden for convert-ly
unless we have a global (or per lyric definition) \noAutomaticExtender
rule that is inserted by default.

On the other hand, there is the chance to get rid of scores where
users don't add extenders simply because they are not aware of their
importance or the proper syntax.

My gut feeling says: Yes, this is an improvement and should be there by
default. IIUC the reason why this has to be discussed is because that
could change/break existing scores, right?

Correct. Change: yes, for sure; break: hardly, unless non-standard
adjustments to lyrics have been made.

If so, could you please think about an example where the patch would
have a negative impact that can't reasonably be caught by convert-ly?
Just because you two are much more into the topic, so that could help us
others understand ...

The only difficult situation for an automatic conversion that I can
think of is the following:
Attached is a modified version of the "divisi lyrics" example from NR
2.1.2, along with a modified version of \autoextenders that alleviates
the severity and offers a way out. The file features a slightly
different approach to divisi lyrics, where the second voice persists
over the entire length of music, but some notes are skipped in the
lyrics with _.

The short stub extenders after "We" and in the third lyrics line will be
removed by Knut's patch, so they are not a problem (the picture is made
from an unpatched Lily version). The issue is with the long extenders
after "will" without corrections. That's because the several _ _ in the
lyrics create a melisma over several notes, which is semantically wrong,
but visually indistinguishable from the correct semantics; hence, I
could imagine that this notation has been used in several scores with
divisi lyrics. I'm no exception myself.

My guess is that a convert-ly rule that translates every occurence of
word _
to
\once \override LyricText.self-alignment-X = #LEFT word \markup{\null}
or
\once \override LyricText.self-alignment-X = #LEFT word ""
will be sufficient to resolve it, but I'm not sure how robust this
approach is. This fakes the melisma by left-alignment, but semantically
leaves "word" assigned to only one note.
"" gives a warning "LyricText has empty extent and non-empty stencil.",
though; for the more verbose \markup{\null} I can't figure out how to
leave out the braces: \markup \null translates to (markup #:null) in
Scheme, but the Scheme construct (markup #:null) creates (markup #:line
(#:null)) somewhere on the way, and those don't compare equal...

For "normal" lyrics, it's difficult to tell. I cannot imagine a
"negative" impact in the sense that readability is affected for proper
lyrics. But at least there is a change.

E.g., I took some (more or less) random piece from CPDL - have a look at
http://www.uma.es/victoria/pdf/Cum_Beatus_Ignatius.pdf
A typical renaissance piece with typical notation (no slurs). Alvarez is
clearly aware of extenders and uses them, e.g. in m. 43. However, he
decided not to add them at other places, e.g. for the very first word of
the canto or in the final bars m. 100 - 102. I guess that this is
deliberate decision and not lazyness, and the same is done throughout
his other scores.

I could e.g. imagine that some editor distinguishes for { b2~ | b r } in
m. 53: with extender, hold the entire value of the note; without, you're
allowed to stop earlier, e.g. on the barline. Not saying that this is
Alvarez' intention, or that this is a good or bad interpretation, but
you never know. At least, it would be an explanation for having
extenders only here and there.

But I'm confident that in most cases (basically, short of misusing
lyrics for other means), the changes will not deteriorate the appearance
and readability, rather the contrary.

Cheers,
Alexander
\version "2.19"

autoextenders =
#(define-music-function (lyrics) (ly:music?)
(let* ((has-hyphen?
(lambda (event)
(let* ((art (ly:music-property event 'articulations))
(is-hyphen? (lambda (ev) (eq? (ly:music-property ev 'name) 'HyphenEvent
(find is-h

68 matches

Mail list logo