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/*
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/*
>> (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/*
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/*
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
Fix scripts for environments where "set -ux" carries over (issue 319870043 by truer...@gmail.com)
LGTM. https://codereview.appspot.com/319870043/ ___ 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 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/*
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/*
On Fri, Dec 16, 2016 at 8:11 AM, David Nalesnikwrote: > 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/*
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:07 AM, Knut Petersenwrote: > 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.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/*
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/*
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: linux-ppc harfbuzz GUB build error
>>> In my environments, autoconf does not raise such error. >>> Do you set the "set -u" or "set -o nounset" somewhere? >>> If so, would you remove the setting? >> The set -u (or to be complete set -ux) I discovered inside >> >> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh >> >> which was the command that was called when the error was signalled > > I've noticed that smart-autogen.sh has "set -ux" and it is invoked from GUB. > If I understand correctly, "set -u" and "set -x" etc. do not carry over > into child processes. > > However, at least in your log file, > "set -x" seems to be carried over to the child process. > From smart-autogen.sh through autogen.sh to autoconf, > all scripts are setted trace mode. > [...snip...] > > Perhaps, also "set -u" is carried over in your environment > and it is not carried over in my environment. > > I have no idea. > But, in CentOS, /bin/sh is symbolic link to bash, > whereas in Ubuntu, /bin/sh is dash. > I think that this difference is influenced. Anyway, I've noticed that if the environment variable SHELLOPTS exists, "set -ux" and "set -e" carry over to the child processes. There may be other conditions that it carries over. In order to avoid this issue, there is a way to "set +ux" before invoking the child process. So I've created a patch for LilyPond's smart-autogen.sh and smart-configure.sh. https://sourceforge.net/p/testlilyissues/issues/5013/ https://codereview.appspot.com/319870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: linux-ppc harfbuzz GUB build error
>>> Maybe the issue is to use ICU of CentOS system. >>> >>> I've created a patch. >>> https://github.com/trueroad/gub/commit/081cc91f698186795dca45e8d6db8af6616826d4 >>> >>> If this patch solves the issue, I will send the pull request. >> >> New gub bootstrapped from you repo; running a trialbuild tonight… more to >> follow tomorrow >> > New build from Masamichi’s branch passed the linux ppc harfbuzz, so the ICU > patch worked. Now looking into a breaking freebsd-x86 lilypond error: I've created the harfbuzz ICU pull request. https://github.com/gperciva/gub/pull/33 ___ 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