Re: music function to be included somewhere in scm/*
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/*
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/*
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/*
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
Re: music function to be included somewhere in scm/*
Hi Urs! 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 ... For the changes to the lyric-extender.cc: There is no "__": nothing changes. There is a melisma and "__" in the lyrics: = Old behaviour: print an extender line. Even if there is no place: print an extender line New behaviour: print an extender line only if the extender line is longer than minimum-length. There is no melisma but there is "__" in the lyrics. == Old behaviour: print a short extender line. New behaviour: print an extender line of minimum-length only if forced by the new force-extender boolean property. In other words: Never ever print an extender line if there is no melisma unless forced with new syntax. Some code needs to be (and can be) converted, e.g. http://lsr.di.unimi.it/LSR/Item?id=1006 Advantages: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. cu, Knut ___ 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/*
Hi Knut, On Wed, Dec 14, 2016 at 3:16 AM, 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. > > To allow automated creation of lyric extenders a helper function is needed. > 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? > The right place to define a music function is in ly/music-functions-init.ly. Supporting Scheme functions might go in scm/music-functions.scm. David ___ 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/*
On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. Would it be possible/wanted to have this triggered by a context property as well? I for one would prefer that, it’s easier to use. Best, Simon ___ 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/*
Am 14.12.2016 um 18:03 schrieb Simon Albrecht: On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. Would it be possible/wanted to have this triggered by a context property as well? I for one would prefer that, it’s easier to use. LyricEvents are generated by the following code in music-functions.scm: (define-public (make-lyric-event string duration) (make-music 'LyricEvent 'duration duration 'text string)) Here only a few lines of code are enough to add LyricExtender events for every syllable by default. Of course we would need to disable the warning about more than one extender event. But do we want to enable lyric extenders by default? Cheers, Knut ___ 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/*
Am 14. Dezember 2016 18:03:09 MEZ, schrieb Simon Albrecht : >On 14.12.2016 14:54, Knut Petersen wrote: >> With a music function \autoextenders that adds extender events to >> every syllable you >> - can be sure never to forget extenders, >> - can be sure never to generate too short extenders >> - can use the same lyrics definition for voices that require >extenders >> at different places. >> >> Nobody is forced to use \autoextenders, manual definition is still >> possible. > >Would it be possible/wanted to have this triggered by a context >property >as well? I for one would prefer that, it’s easier to use. From my perspective this would make sense. The extender behaviour is actually a property of the Lyrics context and not something that shiuld be applied to a music expression. Urs > >Best, Simon -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ 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/*
Hi Alexander, in your example, the last line is just a mockup, isn't it? It is not done by the proposed function? The extender after "We" in the last line is unexpected for me. Cheers, Joram ___ 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/*
On 2016-12-14 21:36, Noeck wrote: Hi Alexander, in your example, the last line is just a mockup, isn't it? It is not done by the proposed function? The extender after "We" in the last line is unexpected for me. Hi, not a mockup, but not the real thing either. I sent this from a PC with the "official" unstable version, without Knut's modification, and I did not fake the effect of the patch. With Knut's proposed addition, it looks as attached (and as you expect). 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/*
On 2016-12-14 19:46, Knut Petersen wrote: Am 14.12.2016 um 18:03 schrieb Simon Albrecht: On 14.12.2016 14:54, Knut Petersen wrote: With a music function \autoextenders that adds extender events to every syllable you - can be sure never to forget extenders, - can be sure never to generate too short extenders - can use the same lyrics definition for voices that require extenders at different places. Nobody is forced to use \autoextenders, manual definition is still possible. Would it be possible/wanted to have this triggered by a context property as well? I for one would prefer that, it’s easier to use. LyricEvents are generated by the following code in music-functions.scm: (define-public (make-lyric-event string duration) (make-music 'LyricEvent 'duration duration 'text string)) Here only a few lines of code are enough to add LyricExtender events for every syllable by default. Yes. In fact, it's more straightforward to add it here than with the extra music function. Not sure how a context property would come into play here; I guesss that'd mean that make-lyric-event branches on a variable named, say, autoAddExtenders, and adds an ExtenderEvent if and only if it is set to #t? Not sure how to code that part, but it seems plausible that we can make that work. Of course we would need to disable the warning about more than one extender event. And we might need to offer a way to remove a LyricExtender event. Unless we go the radical route and ... But do we want to enable lyric extenders by default? ... have them enabled by default, get rid of ExtenderEvent entirely, and just assume it's there for every syllable, unless there is a HyphenEvent (any use case for hyphen + extender?). If a user doesn't want it, we need to provide a function \extenderOff (that translates, e.g., to \override LyricExtender.stencil = ##f). Only thing to consider there: We'd need a "stop sign" for extenders that shall only extend to some point in a _ _ _ sequence, as required in a divisi lyrics setting. 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/*
Hi Alexander, hi everybody! And we might need to offer a way to remove a LyricExtender event. Unless we go the radical route and ... After a bit of thinking I'd say: go the radical route. Attached is a patch against current master that implements it that way. An additional no-extender property is added that can only be overridden by the force-extender property. If a user doesn't want it, we need to provide a function \extenderOff (that translates, e.g., to \override LyricExtender.stencil = ##f). \layout { \Lyrics \override LyricExtender.no-extender = ##t } Only thing to consider there: We'd need a "stop sign" for extenders that shall only extend to some point in a _ _ _ sequence, as required in a divisi lyrics setting. "" and \markup\null are usefull, see 5th exampled in attached lyrextest.ly/pdf I know that the documentation would need some work, but there is no reason to start with that until it is known that the changed code would be accepted. Please test ... cu, Knut >From 53e80c9c17cfa2b11deb15ccfef4587b82c06d52 Mon Sep 17 00:00:00 2001 From: Knut Petersen Date: Thu, 15 Dec 2016 12:52:06 +0100 Subject: [PATCH] Automated lyric extenders Automatically add lyric extenders whenever they are appropriate. Add new property no-extender to forbid all extenders unless overridden by the 2nd new boolean property force-extender. Enabled by default. Signed-off-by: Knut Petersen --- lily/lyric-extender.cc| 44 +-- scm/define-context-properties.scm | 2 ++ scm/define-grob-properties.scm| 6 ++ scm/define-grobs.scm | 2 ++ scm/music-functions.scm | 12 --- 5 files changed, 43 insertions(+), 23 deletions(-) diff --git a/lily/lyric-extender.cc b/lily/lyric-extender.cc index 8afe2c5569..f7d49ac916 100644 --- a/lily/lyric-extender.cc +++ b/lily/lyric-extender.cc @@ -45,51 +45,53 @@ Lyric_extender::print (SCM smob) common = common->common_refpoint (me->get_system (), X_AXIS); Real sl = me->layout ()->get_dimension (ly_symbol2scm ("line-thickness")); + bool at_start_of_line = !left_edge->internal_has_interface (ly_symbol2scm ("lyric-syllable-interface")); + bool at_end_of_line = me->get_bound (RIGHT)->break_status_dir (); + bool force_extender = to_boolean (me->get_property ("force-extender")); + bool no_extender = to_boolean (me->get_property ("no-extender")); + + if (!force_extender && no_extender) +return SCM_EOL; extract_grob_set (me, "heads", heads); - if (!heads.size ()) + if (!heads.size () || (!force_extender && !at_start_of_line && !at_end_of_line && heads.size () < 2)) return SCM_EOL; common = common_refpoint_of_array (heads, common, X_AXIS); Real left_point = 0.0; - if (left_edge->internal_has_interface (ly_symbol2scm ("lyric-syllable-interface"))) + if (!at_start_of_line) left_point = left_edge->extent (common, X_AXIS)[RIGHT]; - else if (heads.size ()) -left_point = heads[0]->extent (common, X_AXIS)[LEFT]; else -left_point = left_edge->extent (common, X_AXIS)[RIGHT]; +left_point = heads[0]->extent (common, X_AXIS)[LEFT]; if (isinf (left_point)) return SCM_EOL; - /* It seems that short extenders are even lengthened to go past the - note head, but haven't found a pattern in it yet. --hwn 1/1/04 */ - SCM minlen = me->get_property ("minimum-length"); - Real right_point -= left_point + (robust_scm2double (minlen, 0)); - - right_point = min (right_point, me->get_system ()->get_bound (RIGHT)->relative_coordinate (common, X_AXIS)); - - if (heads.size ()) -right_point = max (right_point, heads.back ()->extent (common, X_AXIS)[RIGHT]); - Real h = sl * robust_scm2double (me->get_property ("thickness"), 0); Drul_array paddings (robust_scm2double (me->get_property ("left-padding"), h), robust_scm2double (me->get_property ("right-padding"), h)); + Real minlen = robust_scm2double (me->get_property ("minimum-length"), 0); + + Real right_point = heads.back ()->extent (common, X_AXIS)[RIGHT]; + + if (force_extender) +right_point = max (heads.back ()->extent (common, X_AXIS)[RIGHT], left_point + minlen); + if (right_text) right_point = min (right_point, (robust_relative_extent (right_text, common, X_AXIS)[LEFT] - paddings[RIGHT])); - /* run to end of line. */ - if (me->get_bound (RIGHT)->break_status_dir ()) + if (at_end_of_line) right_point = max (right_point, (robust_relative_extent (me->get_bound (RIGHT), common, X_AXIS)[LEFT] - paddings[RIGHT])); - left_point += paddings[LEFT]; + if (!at_start_of_line) +left_point += paddings[LEFT]; + Real w = right_point - left_point; - if (w < 1.5 * h) + if (w < minlen && !at_start_of_line && !at_end_of_line && !force_extender) return SCM_EOL; Stencil mol (Lookup::round_filled_box (Box (Interval (0, w), @@ -111,4 +113,6 @@ ADD_INTERFACE (Lyric_extender, "next "
Re: music function to be included somewhere in scm/*
> Attached is a patch against current master that implements it that > way. An additional no-extender property is added that can only be > overridden by the force-extender property. Nice! However, I'm not happy with the name `minimum-length': It implies that this value sets the minimum length of extender lines, which is not true. What about `minimum-space' or `show-length'? Werner ___ 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/*
Hi Werner! Nice! However, I'm not happy with the name `minimum-length': It implies that this value sets the minimum length of extender lines, which is not true. What about `minimum-space' or `show-length'? minimum-length has been a property of the engraver for a long time. It never implemented the functionality you would expect from a minimum-length property at other places of lilypond. Removing it would break older scores more than necessary, so I strongly feel the need to keep it. minimum-length in my patch means: - Don't generated automatic extenders if it's impossible to give them minimum-length. - Use minimum-length for forced extenders at unusual places (single note) if possible. I think the most reasonable way is to keep that traditional name. cu, Knut ___ 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/*
On 15.12.2016 13:34, Knut Petersen wrote: After a bit of thinking I'd say: go the radical route. Attached is a patch against current master that implements it that way. I like it, and I’d say: go ahead. Best, Simon ___ 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/*
On 15.12.2016 01:34, Alexander Kobel wrote: any use case for hyphen + extender? No. Best, Simon ___ 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/*
Hi Knut, hi everybody. On 2016-12-15 13:34, Knut Petersen wrote: Hi Alexander, hi everybody! And we might need to offer a way to remove a LyricExtender event. Unless we go the radical route and ... After a bit of thinking I'd say: go the radical route. Attached is a patch against current master that implements it that way. Beautiful. I was afraid of the amount of work this requires, but it's also my preferred approach. And it looks like the issue popped up at the right time, with a capable person taking care of the dirty details... :-) An additional no-extender property is added that can only be overridden by the force-extender property. If a user doesn't want it, we need to provide a function \extenderOff (that translates, e.g., to \override LyricExtender.stencil = ##f). \layout { \Lyrics \override LyricExtender.no-extender = ##t } I like that. Only thing to consider there: We'd need a "stop sign" for extenders that shall only extend to some point in a _ _ _ sequence, as required in a divisi lyrics setting. "" and \markup\null are usefull, see 5th exampled in attached lyrextest.ly/pdf Works like a charm. If "" is to be recommended in the docs (and I think \markup\null is too verbose for that purpose), we should make sure that the warning: LyricText has empty extent and non-empty stencil. is not issued in that case. I know that the documentation would need some work, but there is no reason to start with that until it is known that the changed code would be accepted. Makes sense. I'm perfectly happy with that patch. Let's wait for some more opinions. Thanks and 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/*
>> What about `minimum-space' or `show-length'? > > minimum-length has been a property of the engraver for a long > time. It never implemented the functionality you would expect from > a minimum-length property at other places of lilypond. Removing it > would break older scores more than necessary, so I strongly feel the > need to keep it. I disagree. We have convert-ly exactly for such changes. But maybe it's only me who think that the property name is confusing... Werner ___ 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/*
On 15.12.2016 17:17, Francisco Vila wrote: I think lyrics extenders are meant only for the last syllable of a word. Of course they are. That’s why the proposed code checks for any hyphens before adding an extender. Any syllable which is not the last of a word must have a hyphen. Best, Simon ___ 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/*
Knut Petersen wrote Thursday, December 15, 2016 1:55 PM > minimum-length in my patch means: > - Don't generated automatic extenders if it's impossible to give them > minimum-length. > - Use minimum-length for forced extenders at unusual places (single note) if > possible. > > I think the most reasonable way is to keep that traditional name. I don't understand what you mean for the proposed behaviour. Currently, I set minimum-length = 0 in all Lyric contexts so that I can place identical lyrics in several voices, all with extenders, but the extenders appear in the score only when they correspond to melismata. In other words the extender is permitted to reduce in size to 0, which seems pretty well what "minimum-length" means. Will this behaviour change with your proposed patch? Trevor ___ 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/*
Excuse my brevity for now, but I think lyrics extenders are meant only for the last syllable of a word. What does Gould say, for example? I can check later, @home. ___ 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/*
Am 15.12.2016 um 17:19 schrieb Trevor Daniels: Currently, I set minimum-length = 0 in all Lyric contexts so that I can place identical lyrics in several voices, all with extenders, but the extenders appear in the score only when they correspond to melismata. In other words the extender is permitted to reduce in size to 0, which seems pretty well what "minimum-length" means. Will this behaviour change with your proposed patch? Yes. If you need an extender after "X" in one place and an extender after "Y" in another place, you could use your method and define foo = \lyricmode { xx X __ yy Y __ zz }. With my patch you would simply use foo = \lyricmode { xx X yy Y zz } to get the same result, an extender after "X" in one place and after "Y" in another place. ___ 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/*
On 2016-12-15 17:19, Trevor Daniels wrote: Knut Petersen wrote Thursday, December 15, 2016 1:55 PM minimum-length in my patch means: - Don't generated automatic extenders if it's impossible to give them minimum-length. - Use minimum-length for forced extenders at unusual places (single note) if possible. I think the most reasonable way is to keep that traditional name. I don't understand what you mean for the proposed behaviour. Currently, I set minimum-length = 0 in all Lyric contexts so that I can place identical lyrics in several voices, all with extenders, but the extenders appear in the score only when they correspond to melismata. With the effect that sometimes you'll have extenders that are merely flyspecks, yes. In other words the extender is permitted to reduce in size to 0, which seems pretty well what "minimum-length" means. Will this behaviour change with your proposed patch? Yes: it will improve. (1) You can put the lyrics to all voices, as extenders are only printed on melismata (unless explicitly enforced). (2) You don't have to add __ in your lyrics anymore - it's done automagically (unless explicitly disabled). (3) minimum-length (or some other name) is used to control appearance (right now, you "abuse" it to fake semantics). Explanation for (3): On short melismata you'll often want to hide extenders if the syllable has (almost) the same horizontal extent as the music. That's dependent on line breaks etc., so you'll optimally want a minimum-length /strictly/ larger than 0 (to ensure that you don't have the previously mentioned flyspecks), but smaller than, say, 2 staff spaces. So extenders that have a natural length of 2 units are printed, shorter ones aren't. IMHO, setting minimum-length to 0 is an ingenious workaround for a missing functionality (namely, disabling extenders on non-melismata), but it means that you lose the functionality it is intended for. AFAICS, nothing will change for your existing scores. 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/*
Alexander Kobel and Knut Petersen wrote Thursday, December 15, 2016 4:45 PM OK, thanks for your explanations. Clearly the patch is an improvement for this use case: > On 2016-12-15 17:19, Trevor Daniels wrote: > > Currently, I set minimum-length = 0 in all Lyric contexts so that I > can place identical lyrics in several voices, all with extenders, but > the extenders appear in the score only when they correspond to melismata. > In other words the extender is permitted to reduce in size to 0, which > seems pretty well what "minimum-length" means. Another common use case occurs when the lyrics in several verses have melismata in different places. This is usually indicated with dashed slurs, occasionally even with two such slurs starting on the same note. When there are many of these the easiest way is simply to turn off auto-melismata with \set melismaBusyProperties = #'() and indicate them with __ and _ manually in the lyrics. Presumably this behaviour will not change with your proposed patch? Trevor ___ 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/*
Am 15.12.2016 um 17:17 schrieb Francisco Vila: Excuse my brevity for now, but I think lyrics extenders are meant only for the last syllable of a word. What does Gould say, for example? I can check later, @home. I don't know what Gould says, but you are right. Nothing else is proposed. Knut ___ 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/*
Am 15. Dezember 2016 18:58:13 MEZ, schrieb Knut Petersen : >Am 15.12.2016 um 17:17 schrieb Francisco Vila: >> >> Excuse my brevity for now, but I think lyrics extenders are meant >only for the last syllable of a word. What does Gould say, for example? >I can check later, @home. >> >I don't know what Gould says, but you are right. Nothing else is >proposed. I'd suppose that within words hyphens are implicitly created like before? Urs > >Knut > > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ 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/*
Hi Trevor, Another common use case occurs when the lyrics in several verses have melismata in different places. This is usually indicated with dashed slurs, occasionally even with two such slurs starting on the same note. When there are many of these the easiest way is simply to turn off auto-melismata with \set melismaBusyProperties = #'() and indicate them with __ and _ manually in the lyrics. Presumably this behaviour will not change with your proposed patch? You would leave out the "__" part everywhere. Have a look at lyrextest.ly and lyrextest.pdf I sent to the list a few hours ago. That should answer most of your questions. The "__" is still understood, but it is not needed. cu, Knut ___ 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/*
Hi Urs! I'd suppose that within words hyphens are implicitly created like before? Yes. Nothing in this patch touches the hyphen engraver ... cu, Knut ___ 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/*
Am 15.12.2016 um 16:46 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 ... cu, Knut ___ 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/*
>> 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/ Werner ___ 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/*
On 15.12.2016 17:45, Alexander Kobel wrote: (1) You can put the lyrics to all voices, as extenders are only printed on melismata (unless explicitly enforced). (2) You don't have to add __ in your lyrics anymore - it's done automagically (unless explicitly disabled). (3) minimum-length (or some other name) is used to control appearance (right now, you "abuse" it to fake semantics). This is a _huge_ improvement and new feature! I’ll be thrilled to see it in the code base. Best, Simon ___ 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/*
Knut Petersen wrote Thursday, December 15, 2016 6:08 PM >> Another common use case occurs when the lyrics in several verses have >> melismata in different places. This is usually indicated with dashed slurs, >> occasionally even with two such slurs starting on the same note. When >> there are many of these the easiest way is simply to turn off auto-melismata >> with \set melismaBusyProperties = #'() and indicate them with __ and _ >> manually in the lyrics. Presumably this behaviour will not change with your >> proposed patch? > > You would leave out the "__" part everywhere. > > Have a look at lyrextest.ly and lyrextest.pdf I sent to the list a few hours > ago. > That should answer most of your questions. > > The "__" is still understood, but it is not needed. Great! I'm looking forward to a much easier time setting choral pieces for my choir! Many thanks to you and Alexander for all your work and the prompt replies! Trevor ___ 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/*
On December 15, 2016 8:41:14 PM GMT+01:00, Simon Albrecht wrote: >On 15.12.2016 17:45, Alexander Kobel wrote: >> (1) You can put the lyrics to all voices, as extenders are only >> printed on melismata (unless explicitly enforced). >> (2) You don't have to add __ in your lyrics anymore - it's done >> automagically (unless explicitly disabled). >> (3) minimum-length (or some other name) is used to control appearance > >> (right now, you "abuse" it to fake semantics). > >This is a _huge_ improvement and new feature! I’ll be thrilled to see >it >in the code base. > >Best, Simon +1. And the most surprising thing about it is that I had a (slightly less elegantly scheme-d, but still working) solution in my toolbox and posted on the list years ago, and never noticed its potential. So a big thanks to Joram! Usability-wise, that's the most drastic improvement for my typical Lilypond work I can imagine... 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/*
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. 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. We do not need "__", so eliminate it: sed -e "s/__//g" Ok, that looks good. But wait: There is a melisma, and it would be longer than minimum-length, the new engraver adds an extender line. But there is no "__", so the old code did not engrave an extender line. Ok, add an override to be sure there is no extender with the new code. 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. 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. cu, Knut ___ 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/*
> 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. `Exactly the same' should not be the goal IMHO – we have to freeze the sources (similar to TeX) to achieve that. The output should rather be `reasonable'. > We do not need "__", so eliminate it: sed -e "s/__//g" > > Ok, that looks good. But wait: There is a melisma, and it would be > longer than minimum-length, the new engraver adds an extender line. > But there is no "__", so the old code did not engrave an extender > line. Ok, add an override to be sure there is no extender with the > new code. 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. Well, we had similar, incompatible updates already. The usual route was to make `convert-ly' try the best and emit a message Not smart enough to convert foo. Please refer to the manual for details, and update manually. Werner ___ 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/*
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
Re: music function to be included somewhere in scm/*
Am 16.12.2016 um 02:09 schrieb Alexander Kobel: Hi all. [...] What about hide-below-length or hide-if-shorter-than? minimum-visibility? Just my 2ct, Marc ___ 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/*
On 16.12.2016 08:30, Marc Hohl wrote: Am 16.12.2016 um 02:09 schrieb Alexander Kobel: Hi all. [...] What about hide-below-length or hide-if-shorter-than? minimum-visibility? We’re getting closer… I think ‘threshold’ describes the functionality well; maybe visibility-threshold? printing-threshold? extender-threshold? Best, Simon ___ 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/*
Hi Alexander et. al.! For me scheme still is the most counterintuitive way to program a computer. I believe that I discovered a thousand ways to trigger the message "[...] warning: Ignoring non-music expression". Could we switch to something easy like postscript or x86 assembly? ;-)) As your knowledge of scheme seems to be well developed, could you give a scheme equivalent of forceExtender = { \once \override LyricExtender.force-extender = ##t } that is acceptable to lilypond? cu, Knut ___ 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/*
Am 16. Dezember 2016 14:31:43 MEZ, schrieb Knut Petersen : >Hi Alexander et. al.! > >For me scheme still is the most counterintuitive way to program a >computer. I believe that I discovered a >thousand ways to trigger the message "[...] warning: Ignoring >non-music expression". Could we switch >to something easy like postscript or x86 assembly? ;-)) > >As your knowledge of scheme seems to be well developed, could you give >a scheme equivalent of > >forceExtender = { \once \override LyricExtender.force-extender = ##t } > >that is acceptable to lilypond? #(once (overrideProperty '(LyricExtender force-extender) #t)) (untested) HTH Urs > >cu, > Knut -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ 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/*
Am 16.12.2016 um 14:38 schrieb Urs Liska: As your knowledge of scheme seems to be well developed, could you give a scheme equivalent of forceExtender = { \once \override LyricExtender.force-extender = ##t } that is acceptable to lilypond? #(once (overrideProperty '(LyricExtender force-extender) #t)) (untested) Thanks a lot for the quick answer. If I put (define-public (forceExtender) (once (overrideProperty '(LyricExtender force-extender) #t))) into scm/music-functions.scm, lilypond does know \forceExtender ... but it complains about a "non-music expression" if it is used ... Cheers, Knut ___ 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/*
On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen wrote: > Am 16.12.2016 um 14:38 schrieb Urs Liska: >> >> >>> As your knowledge of scheme seems to be well developed, could you give >>> a scheme equivalent of >>> >>> forceExtender = { \once \override LyricExtender.force-extender = ##t } >>> >>> that is acceptable to lilypond? >> >> #(once (overrideProperty '(LyricExtender force-extender) #t)) >> >> (untested) > > Thanks a lot for the quick answer. If I put > > (define-public (forceExtender) > (once (overrideProperty '(LyricExtender force-extender) #t))) > > into scm/music-functions.scm, lilypond does know \forceExtender ... but it > complains about a "non-music expression" > if it is used ... If you are defining a music function, do it in ly/music-functions-init.ly, ___ 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/*
Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik : >On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen > wrote: >> Am 16.12.2016 um 14:38 schrieb Urs Liska: >>> >>> As your knowledge of scheme seems to be well developed, could you >give a scheme equivalent of forceExtender = { \once \override LyricExtender.force-extender = >##t } that is acceptable to lilypond? >>> >>> #(once (overrideProperty '(LyricExtender force-extender) #t)) >>> >>> (untested) >> >> Thanks a lot for the quick answer. If I put >> >> (define-public (forceExtender) >> (once (overrideProperty '(LyricExtender force-extender) #t))) >> >> into scm/music-functions.scm, lilypond does know \forceExtender ... >but it >> complains about a "non-music expression" >> if it is used ... Ah, this one. You explicitly have to create a music function. Maybe https://scheme-book.ursliska.de/scheme/music-function-primer.html helps you? But you can say (define forceExtender (define-musi-function ... HTH Urs > > >If you are defining a music function, do it in >ly/music-functions-init.ly, -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ 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/*
On Fri, Dec 16, 2016 at 8:11 AM, David Nalesnik wrote: > On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen > wrote: >> Am 16.12.2016 um 14:38 schrieb Urs Liska: >>> >>> As your knowledge of scheme seems to be well developed, could you give a scheme equivalent of forceExtender = { \once \override LyricExtender.force-extender = ##t } that is acceptable to lilypond? >>> >>> #(once (overrideProperty '(LyricExtender force-extender) #t)) >>> >>> (untested) >> >> Thanks a lot for the quick answer. If I put >> >> (define-public (forceExtender) >> (once (overrideProperty '(LyricExtender force-extender) #t))) >> >> into scm/music-functions.scm, lilypond does know \forceExtender ... but it >> complains about a "non-music expression" >> if it is used ... > > > If you are defining a music function, do it in ly/music-functions-init.ly, Or if it's simply setting a property, as here, in ly/property.init.ly ... ___ 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/*
On 2016-12-16 15:20, Urs Liska wrote: Am 16. Dezember 2016 15:11:59 MEZ, schrieb David Nalesnik : On Fri, Dec 16, 2016 at 8:07 AM, Knut Petersen [...] (define-public (forceExtender) (once (overrideProperty '(LyricExtender force-extender) #t))) into scm/music-functions.scm, lilypond does know \forceExtender ... but it complains about a "non-music expression" if it is used ... Ah, this one. You explicitly have to create a music function. Maybe https://scheme-book.ursliska.de/scheme/music-function-primer.html helps you? Oh, that looks nice... I need to spend some time on that one. But you can say (define forceExtender (define-musi-function ... (define forceExtender (define-music-function () () (once (overrideProperty '(LyricExtender force-extender) #t should work, yes. But I think David's suggestion is even easier and recommended. Note that fgrep define-music-function scm/* gives a pretty short list of 4 hits, and 2 of which are in the definition of define-music-function itself. And fgrep define-music-function ly/* | wc -l shows a count of 131... If you are defining a music function, do it in ly/music-functions-init.ly, In a .ly file (which is processed with all the syntactic sugar that Lilypond has to offer) you can simply write forceExtender = \once \override LyricExtender.force-extender = ##t and that's it. By the way, for the sake of consistency with other commands (except, maybe, \hideNotes and \unHideNotes): My preferred choice of names would be forcedExtendersOn = \override LyricExtender.force-extender = ##t forcedExtendersOff = \override LyricExtender.force-extender = ##f and a user can prefix a \once if necessary. (Unless someone comes up with an apt antonym of "force" here - free, release, permit don't sound sound...) 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/*
Hi Knut and everyone, Great to see your work which seems like a nice improvement. I just have some thoughts on the implementation / use of properties. We are just talking about grob properties and not context properties right? In that case no need to also create context properties as you do in your patch, since the grob properties are sufficient. What about a way to do this with fewer than 3 separate grob properties? LyricExtender.minimum-length LyricExtender.no-extender LyricExtender.force-extender If I understand correctly, only 1 of 3 kinds of behavior can be in effect at a given point: 1. no extensions 2. forced extensions 3. automatically added extension depending on a 'minimum-length' number So why not one grob property (name to be determined) that can be a boolean or a number: LyricExtender.extenders = ##f % no extensions LyricExtender.extenders = ##t % forced extensions LyricExtender.extenders = 2% a number, auto extensions For example, it could be set to a number and then use \once to set it to ##t to force (or ##f to suppress) a given extender. Another possibility (2 properties) might be: LyricExtender.stencil = ##f% no extensions LyricExtender.force-extender = ##t % forced extensions LyricExtender.minimum-length = 2% auto extensions (if force-extender is not ##t and stencil is not ##f) Am I missing something? What do you think? Cheers, -Paul ___ 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/*
Hi Paul. On 2016-12-16 16:02, Paul wrote: Hi Knut and everyone, Great to see your work which seems like a nice improvement. I just have some thoughts on the implementation / use of properties. We are just talking about grob properties and not context properties right? In that case no need to also create context properties as you do in your patch, since the grob properties are sufficient. Yes, I think that's a general agreement now. AFAICS, the idea of context properties quickly vanished after we recognized that we can get rid of __ (or ExtenderEvents) entirely, at least as far as the user is concerned. They are now more like an implementation detail for no-extender. What about a way to do this with fewer than 3 separate grob properties? LyricExtender.minimum-length LyricExtender.no-extender LyricExtender.force-extender If I understand correctly, only 1 of 3 kinds of behavior can be in effect at a given point: 1. no extensions 2. forced extensions 3. automatically added extension depending on a 'minimum-length' number Not quite. I can imagine that no-extender and force-extender could be combined. E.g., as create-extender = { one of #'auto, #'never, #'always }: #'auto means the default: create extenders on melismata and nowhere else. #'never means: create no extenders, period. #'always means that extenders are enforced even on non-melismata (where, by definition, there should not be an extender; but there are situations where it makes sense to overwrite it; e.g., for a continuation of an extender in a second volta repeat, or in divisi lyrics). Minimum-length [2] is orthogonal - it is more concerned with the layout. With some reasonable minimum-length, extenders that reduce to mere flyspecks are hidden. This happens often in somewhat dense choral settings: the extender is not printed if the syllable text is almost as wide (or even wider) than the distance between the respective noteheads. It's a threshold value that tells which existing extenders will be printed and visible. [1] But this decision entirely depends on horizontal spacing, and will vary with line breaks, other voices, etc. IMHO, that's a whole different quality of a variable than the previous one (existence vs. appearance). And the general design principle throughout Lilypond is to separate semantics from layout as much as possible. [1] One exception: on forced extenders on non-melismata (which do not have any natural length, obviously), minimum-length will not serve as a threshold, but to /set/ the length. [2] Side Note: other proposed names for minimum-length so far: (1) minimum-space (2) show-length (3) hide-below-length (4) hide-if-shorter-than (5) minimum-visibility (6) visibility-threshold (7) printing-threshold (8) extender-threshold So why not one grob property (name to be determined) that can be a boolean or a number: LyricExtender.extenders = ##f % no extensions LyricExtender.extenders = ##t % forced extensions LyricExtender.extenders = 2% a number, auto extensions For example, it could be set to a number and then use \once to set it to ##t to force (or ##f to suppress) a given extender. See [1] above; we need to be able to specify a length for forced extenders (that do not have a natural length because there's only one note). Yes, something like extenders = #'(forced? length) with a boolean for forced? and a number for length would be sufficient (note that #'(#f +inf.0) amounts to #'never...), but that's quite opaque. Another possibility (2 properties) might be: LyricExtender.stencil = ##f% no extensions LyricExtender.force-extender = ##t % forced extensions LyricExtender.minimum-length = 2% auto extensions (if force-extender is not ##t and stencil is not ##f) Yes, that'll work: stencil = ##f means #'never; stencil = ##t and force-extender = ##t means #'always; and stencil = ##t and force-extender = ##f means #'auto. However, I personally dislike to touch stencil. That's my last resort, but it feels hacky; IMHO stencil is a more or less internal layout procedure, and I should not have to abuse it for semantic purposes (i.e., #'never). 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/*
Hi Paul, Alexander et. al! I need to be very short as a rehearsal is waiting. I'd advocate to keep minimum-length. I also need some way to force an extender and to inhibit extender generation. Forcing an individual extender should overrule a general inhibition of extenders. Details can be hidden by some music functions ... but there's not time to generate a patch now. Have a look at the attached ly and the generated pdf ... and comment on the chosen names and syntax. It should be self-explanatory. cu, Knut \version "2.19.53" \paper { #(set-paper-size "a4") ragged-right = ##f left-margin = 1\cm line-width = 19\cm top-margin = 1\cm bottom-margin = 1\cm ragged-bottom = ##f ragged-last-bottom = ##f } \pointAndClickOff #(set-global-staff-size 16) \markup { "automatic extenders, minimum-length 7 "} << { c''1 2 ~ 2 2 4 ~ 4 4 8 ~ 8 8 16 ~ 16 4 1 \bar "|." } \addlyrics { \noExtenderLimit #7 \repeat unfold 5 { foo -- bar }} >> \markup { "automatic extenders, minimum-length 3.5 "} << { c''1 2 ~ 2 2 4 ~ 4 4 8 ~ 8 8 16 ~ 16 4 1 \bar "|." } \addlyrics { \noExtenderLimit #3.5 \repeat unfold 5 { foo -- bar }} >> \markup { "automatic extenders, minimum-length 1 "} << { c''1 2 ~ 2 2 4 ~ 4 4 8 ~ 8 8 16 ~ 16 4 1 \bar "|." } \addlyrics { \noExtenderLimit #1 \repeat unfold 5 { foo -- bar }} >> \markup { "automatic extenders, mixed manual and automatic melismata, extender on last note forced to length 5"} << { \autoBeamOff c''2 2 4\( 4 4 4\) 4 4 4\( 4( 4) 8[ 8] 8\) 16\(\melisma 16\melismaEnd 4\) 1 \bar "|." } \addlyrics { \noExtenderLimit #8 foo -- _ bar _ _ _ foo -- _ bar _ _ _ foo -- _ \forceExtenderTo #5 bar } >> \markup { "automatic extenders, mixed manual and automatic melismata, first extender shortened, extender on last note forced "} << { \autoBeamOff c''2 2 4\( 4 4 4\) 4 4 4\( 4( 4) 8[ 8] 8\) 16\(\melisma 16\melismaEnd 4\) 1 \bar "|." } \addlyrics { \noExtenderLimit #8 foo -- _ \forceExtender bar _ "" _ foo -- _ bar _ _ _ foo -- _ \forceExtender bar _ _ _ } >> \markup { "Issue 1006 revisited, last extender forced and tweaked to the left, minimum-length 2 "} \score { << \new Staff \relative c'' { \time 2/1 \repeat volta 2 { r4 g4 d'2. a4 bes2~ bes a2 g1~ } \alternative{ { g2 fis4 e fis1 d'1 c2 bes} { g\repeatTie fis4 e fis1 } } \bar "|." } \addlyrics { \noExtenderLimit #2 of Prin -- ces all _ _ the _ flowâr. Who took a- \earlyExtender #-4 the _ flowâr. } >> } \markup { "Issue 1006 revisited, last extender forced and tweaked to the left, minimum-length 1 "} \score { << \new Staff \relative c'' { \time 2/1 \repeat volta 2 { r4 g4 d'2. a4 bes2~ bes a2 g1~ } \alternative{ { g2 fis4 e fis1 d'1 c2 bes} { g\repeatTie fis4 e fis1 } } \bar "|." } \addlyrics { \noExtenderLimit #1 of Prin -- ces all _ _ the _ flowâr. Who took a- \earlyExtender #-4 the _ flowâr. } >> } \markup{Here our melisma detection fails. We need to override. } \score { << \new Voice = "singleVoice" { \relative { a'4 a a a \repeat volta 3 { b4 b b b } c4 c c c } } \new Lyrics \lyricsto "singleVoice" { Not re -- peat -- ed. << { The first time words. } \new Lyrics { \set associatedVoice = "singleVoice" Sec -- ond time \noExtender words. } \new Lyrics { \set associatedVoice = "singleVoice" The third time \noExtender words. } >> The end sec -- tion. } >> } \markup {There should be no extender from volta 1 to volta 2 but a short extender starting at volta 2} \score { << \new Staff { \time 2/4 \new Voice = "melody" { \relative { \set melismaBusyProperties = #'() \repeat volta 2 { b'4 b ~} \alternative { { b b } { b \repeatTie c } } \unset melismaBusyProperties c4 c } } } \new Lyrics { \lyricsto "melody" { \repeat volta 2 { Here's a __ } \alternative { { \skip 1 verse } { \earlyExtender #-4 sec -- } } ond one. } } >> } \markup {Best solution to that problem ...} \score { << \new Staff { \time 2/4 \new Voice = "melody" { \relative { \repeat volta 2 { b'4 b ~} \alternative { { b b } { b \repeatTie c } } c4 c } } } \new Lyrics { \lyricsto "melody" { Here's a verse. "" "" } } \new Lyrics { \lyricsto "melody" { Here's \shortenExtender#6 one "" \earlyExtender #-6 more to sing. } } >> } \layout { } lyrextest.pdf Description: Adobe PDF document ___ lilypond-devel mailing list lilypond-devel@gnu.
Re: music function to be included somewhere in scm/*
Am 16.12.2016 um 17:38 schrieb Alexander Kobel: > [2] Side Note: other proposed names for minimum-length so far: > > (1) minimum-space > (2) show-length > (3) hide-below-length > (4) hide-if-shorter-than > (5) minimum-visibility > (6) visibility-threshold > (7) printing-threshold > (8) extender-threshold At a first glance, the property is still the same, just the behaviour for shorter extenders changed: before: shorter extenders are prolonged after: shorter extenders are not visible But at a second glance, the minimum-length for LilyPond grobs usually means that the object is visible and the length is at least minimum-length (for glissandi, etc.). Using it to hide a shorter object feels inconsistent, IMHO. So I agree with Werner. But I have no favourite naming, all of them sound wrong to me - a slight preference for (6). Cheers, Joram ___ 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/*
>> (1) minimum-space >> (2) show-length >> (3) hide-below-length >> (4) hide-if-shorter-than >> (5) minimum-visibility >> (6) visibility-threshold >> (7) printing-threshold >> (8) extender-threshold > > At a first glance, the property is still the same, just the > behaviour for shorter extenders changed: > > before: shorter extenders are prolonged > after: shorter extenders are not visible > > But at a second glance, the minimum-length for LilyPond grobs > usually means that the object is visible and the length is at least > minimum-length (for glissandi, etc.). Using it to hide a shorter > object feels inconsistent, IMHO. So I agree with Werner. But I > have no favourite naming, all of them sound wrong to me - a slight > preference for (6). What about `length-threshold'? Werner ___ 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/*
Noeck wrote Friday, December 16, 2016 9:08 PM > Am 16.12.2016 um 17:38 schrieb Alexander Kobel: >> [2] Side Note: other proposed names for minimum-length so far: >> >> (1) minimum-space >> (2) show-length >> (3) hide-below-length >> (4) hide-if-shorter-than >> (5) minimum-visibility >> (6) visibility-threshold >> (7) printing-threshold >> (8) extender-threshold > > At a first glance, the property is still the same, just the behaviour > for shorter extenders changed: > > before: shorter extenders are prolonged > after: shorter extenders are not visible > > But at a second glance, the minimum-length for LilyPond grobs usually > means that the object is visible and the length is at least > minimum-length (for glissandi, etc.). Using it to hide a shorter object > feels inconsistent, IMHO. So I agree with Werner. But I have no > favourite naming, all of them sound wrong to me - a slight preference > for (6). Definitely not "minimum-length" which means "Try to make a spanner at least this long." How about "collapse-length", which would be analogous to "collapse-height"? This exists already and means "Minimum height of system start delimiter. If equal or smaller, the bracket/brace/line is removed." "remove-threshold" is another possibility. Trevor ___ 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/*
> How about "collapse-length", which would be analogous to > "collapse-height"? This exists already and means "Minimum height of > system start delimiter. If equal or smaller, the bracket/brace/line > is removed." Thanks for finding this property name! I vote for it because of the striking similarity of usage. Note, however, that it would need a small change to the code so that we really have `equal or smaller'. Werner ___ 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/*
On 17.12.2016 00:23, Trevor Daniels wrote: How about "collapse-length", which would be analogous to "collapse-height"? +1 Simon ___ 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/*
Hi, I tested the patch on my scores now (SATB choirs) and it works perfectly. I applied the 0001-Automated-lyric-extenders.patch and it adds the extenders where I had put them by hand before and a few other reasonable places. Before, I made a per-syllable-decision whether I put it or not. Now, a given minimum-length is much more consistent troughout the piece. 1.5 is a reasonable default value in my scores. Explicit __ extenders are printed no matter if it is too short or not. Is that expected? (It makes sense but looks ugly :) But ok, if the users insists.) So, I could not find any drawbacks. It works. The questions about how many properties are needed and how they are called, are going into a good direction, I think. Thanks for your work, Alexander and Knut et al.! Cheers, Joram ___ 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/*
Hi all, On 2016-12-16 19:13, Knut Petersen wrote: Hi Paul, Alexander et. al! I need to be very short as a rehearsal is waiting. same here - I was and still am busy with pre-christmas performances. I'd advocate to keep minimum-length. I second the vote for collapse-length. (I agree with you that minimum-length is not a bad name per se, but the meaning is different for spanners and extenders. For spanners, the description of the property and its functionality matched way better in the past, and users are more aware of that meaning. Now that extenders will be auto-generated, it's even more crucial than before that we avoid confusion.) I also need some way to force an extender and to inhibit extender generation. Forcing an individual extender should overrule a general inhibition of extenders. Details can be hidden by some music functions ... but there's not time to generate a patch now. Have a look at the attached ly and the generated pdf ... and comment on the chosen names and syntax. It should be self-explanatory. It is to me. Thanks. Nevertheless, I guess we are at a point where we get an evaluation of the syntax and behavior by some people that have not been as involved in the feature development as we've been. I have a blind spot for any decisions on syntax as soon as I internalized what the engraving result will be. 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/*
On 2016-12-16 19:13, Knut Petersen wrote: [...] Have a look at the attached ly and the generated pdf ... and comment on the chosen names and syntax. It should be self-explanatory. [...] One more idea (and I feel a bit bad for asking, since I dump the hard work on you again - not sure if I'm able to help): W.r.t. the extenders to the second repeat alternative: spanners have the to-barline property that alleviates the need for manual length tweaks in such situations. Do you think it's possible with reasonable effort (in particular, reusing the code and/or strategy from spanners) to achieve the same effect for extenders? Such that, e.g., in your last example \repeat volta 2 { b'4 b ~} \alternative { { b b } { b \repeatTie c } } c4 c \lyricsto "melody" { Here's a verse. "" "" } \lyricsto "melody" { Here's \once \override LyricExtender.to-barline = ##t one "" \earlyExtender #-6 more to sing } would mean that the extender after "one" (that usually extends to the first note in the first alternative) would be stopped earlier, exactly at the barline? (Of course, in an ideal world, the "early extender" would have a corresponding from-barline property, but I don't think we have any example of such a functionality that we can rely on.) 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/*
I'd advocate to keep minimum-length. I second the vote for collapse-length. Ok, next try: s/minimum-length/length-limit-or-forced-length/g (length-limit-or-forced-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length. A forced lyric extender is given this length if possible.") I still have one problem: \score { %\displayMusic << \new Voice = "singleVoice" { \relative { a'4 a a a \repeat volta 3 { b4 b b b } c4 c c c } } \displayMusic \new Lyrics \lyricsto "singleVoice" { Not re -- peat -- ed. << { The first time words.} \new Lyrics { \set associatedVoice = "singleVoice" Sec -- ond time words. #(make-music (quote CompletizeExtenderEvent)) } \new Lyrics { \set associatedVoice = "singleVoice" The third time words. #(make-music (quote CompletizeExtenderEvent)) } >> } >> } I would like to see a CompletizeExtenderEvent automatically generated at the places indicated above ... I think that this could be possible in the add-lyrics code defined at the end of scm/ly-syntax-constructors.scm. Any ideas how to change the code there? cu, Knut ___ 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/*
>> I second the vote for collapse-length. > > Ok, next try: > > s/minimum-length/length-limit-or-forced-length/g > > (length-limit-or-forced-length ,ly:dimension? "An automatically > generated lyric extender is suppressed if it would be shorter than > this length. A forced lyric extender is given this length if > possible.") Sorry, but I strongly dislike collapsing two properties into one, even if the values for the two properties are always the same. So please use `collapse-length' (`suppress-threshold', etc.) and `forced-length'. Werner ___ 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/*
Hi Werner! (length-limit-or-forced-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length. A forced lyric extender is given this length if possible.") Sorry, but I strongly dislike collapsing two properties into one, even if the values for the two properties are always the same. So please use `collapse-length' (`suppress-threshold', etc.) and `forced-length'. I'll implement whatever the majority agrees upon. Nevertheless: two parameters would obfuscate the fact that the internal logic would always decide to use only one of those lengths and to ignore the other. For the case of two parameters I like best: (forced-length ,ly:dimension? "A forced lyric extender is given this length if possible.") (collapse-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length.") Paul? cu, Knut ___ 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/*
> Nevertheless: two parameters would obfuscate the fact that the > internal logic would always decide to use only one of those lengths > and to ignore the other. You could add something like This parameter is mutually exclusive with @code{forced-length}. to make this more visible. > For the case of two parameters I like best: > > (forced-length ,ly:dimension? "A forced lyric extender > is given this length if possible.") > (collapse-length ,ly:dimension? "An automatically generated > lyric extender is suppressed if it would be shorter than > this length.") LGTM, thanks. Werner ___ 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/*
On Dec 20, 2016, at 08:23 , Werner LEMBERG wrote: > Sorry, but I strongly dislike collapsing two properties into one, even > if the values for the two properties are always the same. So please > use `collapse-length' (`suppress-threshold', etc.) and > `forced-length'. This is wise. — Dan ___ 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/*
Hi Knut, Werner, Alexander, and everyone, On 12/20/2016 08:47 AM, Knut Petersen wrote: Hi Werner! (length-limit-or-forced-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length. A forced lyric extender is given this length if possible.") Sorry, but I strongly dislike collapsing two properties into one, even if the values for the two properties are always the same. So please use `collapse-length' (`suppress-threshold', etc.) and `forced-length'. I'll implement whatever the majority agrees upon. Nevertheless: two parameters would obfuscate the fact that the internal logic would always decide to use only one of those lengths and to ignore the other. For the case of two parameters I like best: (forced-length ,ly:dimension? "A forced lyric extender is given this length if possible.") (collapse-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length.") Paul? I'm fine with using two properties, as Werner prefers, and as in this suggestion from Knut. When I suggested using fewer properties I didn't fully understand all the details. (The music I typeset rarely involves lyric extenders.) Alexander's explanation and further discussions have helped me get it, but I hadn't had a chance to reply sooner. Thanks again for working on this, -Paul ___ 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/*
On Tue, Dec 20, 2016 at 7:41 AM, Paul wrote: > Hi Knut, Werner, Alexander, and everyone, > > On 12/20/2016 08:47 AM, Knut Petersen wrote: > >> Hi Werner! >> >>> (length-limit-or-forced-length ,ly:dimension? "An automatically generated lyric extender is suppressed if it would be shorter than this length. A forced lyric extender is given this length if possible.") >>> Sorry, but I strongly dislike collapsing two properties into one, even >>> if the values for the two properties are always the same. So please >>> use `collapse-length' (`suppress-threshold', etc.) and >>> `forced-length'. >>> >> >> I'll implement whatever the majority agrees upon. >> >> Nevertheless: two parameters would obfuscate the fact that >> the internal logic would always decide to use only one of those >> lengths and to ignore the other. >> >> For the case of two parameters I like best: >> >> (forced-length ,ly:dimension? "A forced lyric extender >> is given this length if possible.") >> (collapse-length ,ly:dimension? "An automatically generated >> lyric extender is suppressed if it would be shorter than >> this length.") >> >> Paul? >> > > I'm fine with using two properties, as Werner prefers, and as in this > suggestion from Knut. > > When I suggested using fewer properties I didn't fully understand all the > details. (The music I typeset rarely involves lyric extenders.) > Alexander's explanation and further discussions have helped me get it, but > I hadn't had a chance to reply sooner. > > Thanks again for working on this, > Yes, thanks for making this possible! It will be a great addition. One question I have about having the two properties is how will the two be reconciled in actual use? In other words, if collapse-length is larger than forced-length, will there still be the same amount of space between syllables even without the extender (to the amount of forced-length)? Maybe the question I really have is this: what does "given this length _if possible_" mean and what governs this possibility? I can totally understand how they work individually, I'm just trying to understand how I can use them well together since it seems that forced-length contradicts collapse-length. Thanks, Abraham ___ 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/*
On 2016-12-20 17:21, Abraham Lee wrote: Yes, thanks for making this possible! It will be a great addition. Thanks Abraham. One question I have about having the two properties is how will the two be reconciled in actual use? In other words, if collapse-length is larger than forced-length, will there still be the same amount of space between syllables even without the extender (to the amount of forced-length)? One thing remains identical to the current situation: Extenders never ever influence horizontal spacing. Maybe the question I really have is this: what does "given this length _if possible_" mean and what governs this possibility? I can totally understand how they work individually, I'm just trying to understand how I can use them well together since it seems that forced-length contradicts collapse-length. You won't really use them together; at least, not both will be effective at the same time: (1) If the natural length (essentially: the distance from the right end of the syllable to the right end of the last note in the corresponding melisma) is less than collapse-length, this extender will not be printed. (2) If you /force/ an extender, that is, you explicitly add one for a syllable that does not belong to a melisma, there is no "natural length" - simply because there is no "natural extender". The "faked" length of such an extender will be given by the minimum of forced-length and the available space to the next syllable. Again, this will not affect the space between the notes. Forced extenders should only be necessary under extraordinary circumstances, such as an extender reaching into a alternative ending of a repeat, re-extending after rests, or even more obscure design studies. 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/*
On 2016-12-20 14:16, Knut Petersen wrote: I still have one problem: \score { %\displayMusic << \new Voice = "singleVoice" { \relative { a'4 a a a \repeat volta 3 { b4 b b b } c4 c c c } } \displayMusic \new Lyrics \lyricsto "singleVoice" { Not re -- peat -- ed. << { The first time words.} \new Lyrics { \set associatedVoice = "singleVoice" Sec -- ond time words. #(make-music (quote CompletizeExtenderEvent)) } \new Lyrics { \set associatedVoice = "singleVoice" The third time words. #(make-music (quote CompletizeExtenderEvent)) } >> } >> } I would like to see a CompletizeExtenderEvent automatically generated at the places indicated above ... I think that this could be possible in the add-lyrics code defined at the end of scm/ly-syntax-constructors.scm. Any ideas how to change the code there? Hi Knut, not really an idea here. I was not even aware that a CompletizeExtenderEvent exists... W.r.t. the << >> issue, not sure whether this is an intended and supported functionality. I'm afraid that it might just work "by accident". Note that a) the music expressions for second and third repeat in your example are not of type LyricCombineMusic, b) that the \set associatedVoice does not seem to do what you think it does (try to add a different voice with a different rhythm, and you'll find that the lyrics still align to "singleVoice"), and c) that, consequently, there is a difference between \new Lyrics { \set associatedVoice = "..." { ... } and \new Lyrics \lyricsto "..." { ... } inside << >>. Given enough time, I should be able to figure out a Scheme workaround that involves promoting the level of the inner expressions. But I'm afraid it will be ugly and probably not very robust; I can translate the expression from one form to the other, but without understanding its meaning and implications entirely. Is there anyone who can comment on the side effects of using this construct, and whether and how it is supposed to work? 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/*
On Wed, Dec 21, 2016 at 5:22 AM, Alexander Kobel-2 [via Lilypond] < ml-node+s1069038n198284...@n5.nabble.com> wrote: > On 2016-12-20 17:21, Abraham Lee wrote: > > Yes, thanks for making this possible! It will be a great addition. > > Thanks Abraham. > > > One question I have about having the two properties is how will the two > be > > reconciled in actual use? In other words, if collapse-length is larger > than > > forced-length, will there still be the same amount of space between > > syllables even without the extender (to the amount of forced-length)? > > One thing remains identical to the current situation: Extenders never > ever influence horizontal spacing. > > > Maybe the question I really have is this: what does "given this length > _if > > possible_" mean and what governs this possibility? I can totally > understand > > how they work individually, I'm just trying to understand how I can use > > them well together since it seems that forced-length contradicts > > collapse-length. > > You won't really use them together; at least, not both will be effective > at the same time: > (1) If the natural length (essentially: the distance from the right end > of the syllable to the right end of the last note in the corresponding > melisma) is less than collapse-length, this extender will not be printed. > (2) If you /force/ an extender, that is, you explicitly add one for a > syllable that does not belong to a melisma, there is no "natural length" > - simply because there is no "natural extender". The "faked" length of > such an extender will be given by the minimum of forced-length and the > available space to the next syllable. Again, this will not affect the > space between the notes. > > Forced extenders should only be necessary under extraordinary > circumstances, such as an extender reaching into a alternative ending of > a repeat, re-extending after rests, or even more obscure design studies. > Ah! I understand now. Thank you for explaining that. So, it's "Force an extender to appear if there is sufficient space (i.e., at least as much as "collapse-length"), even in places they wouldn't normally be used." Is that right? If so, then I think "forced-length" is not the right name for it. Perhaps just "force" or "force-all"? Or is forced appearance not subject to "collapse-length"? Best, Abraham -- View this message in context: http://lilypond.1069038.n5.nabble.com/music-function-to-be-included-somewhere-in-scm-tp197960p198288.html Sent from the Dev mailing list archive at Nabble.com. ___ 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/*
On 2016-12-21 17:05, tisimst wrote: On Wed, Dec 21, 2016 at 5:22 AM, Alexander Kobel-2 [via Lilypond] < ml-node+s1069038n198284...@n5.nabble.com> wrote: On 2016-12-20 17:21, Abraham Lee wrote: Maybe the question I really have is this: what does "given this length _if possible_" mean and what governs this possibility? I can totally understand how they work individually, I'm just trying to understand how I can use them well together since it seems that forced-length contradicts collapse-length. You won't really use them together; at least, not both will be effective at the same time: (1) If the natural length (essentially: the distance from the right end of the syllable to the right end of the last note in the corresponding melisma) is less than collapse-length, this extender will not be printed. (2) If you /force/ an extender, that is, you explicitly add one for a syllable that does not belong to a melisma, there is no "natural length" - simply because there is no "natural extender". The "faked" length of such an extender will be given by the minimum of forced-length and the available space to the next syllable. Again, this will not affect the space between the notes. Forced extenders should only be necessary under extraordinary circumstances, such as an extender reaching into a alternative ending of a repeat, re-extending after rests, or even more obscure design studies. Ah! I understand now. Thank you for explaining that. So, it's "Force an extender to appear if there is sufficient space (i.e., at least as much as "collapse-length"), even in places they wouldn't normally be used." No, it's just "force an extender to appear even in places they wouldn't normally be used". Is that right? If so, then I think "forced-length" is not the right name for it. Perhaps just "force" or "force-all"? Or is forced appearance not subject to "collapse-length"? The latter. It is well possible (and reasonable, given that you need forced extenders at all) to set collapse-length > forced-length. You explicitly ask for an extender to be printed, so you would not want it to be collapsed again. Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel