Re: pdf changes every few compilations, although changing nothing
On Mon, Apr 10, 2017 at 7:43 AM, David Nalesnikwrote: > On Mon, Apr 10, 2017 at 7:21 AM, Thomas Morley > wrote: >> 2017-04-10 14:09 GMT+02:00 David Nalesnik : >>> On Mon, Apr 10, 2017 at 5:36 AM, Thomas Morley >>> wrote: >> Here the best minimal I can come up with: \version "2.19.60" tst = { \override TupletBracket.stencil = #(lambda (grob) (let* ((orig (ly:grob-original grob)) (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '())) (tuplet-number (ly:grob-object grob 'tuplet-number))) (if (or (and (pair? siblings) (equal? grob (car siblings))) (null? siblings)) (ly:grob-set-property! tuplet-number 'X-offset 0)) (ly:tuplet-bracket::print grob))) } %%{ \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } %} %%{ \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } %} >>> >>> I notice the same variability with 2.19.56 and 2.18.2. I'll see if I >>> can figure out more. >> >> >> Hi David, >> >> many thanks for caring. >> >> I meanwhile found using 'after-line-breaking and setting the final >> stencil via ly:grob-set-property! ensures stable behaviour. >> >> Nevertheless I stay highly interested why this happens during a direct >> stencil-override. >> > > Here's an even more minimal example: > > > tst = \override TupletBracket.stencil = > #(lambda (grob) >(let ((tuplet-number (ly:grob-object grob 'tuplet-number))) > (ly:grob-set-property! tuplet-number 'X-offset 0) > (ly:tuplet-bracket::print grob))) > > %%{ > \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } > %} > %%{ > \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } > > %% > > It's strange -- it seems that the value of > ly:tuplet-bracket::calc-x-offset is used sometimes regardless of the > ly:grob-set-property! and there's no predictability to it. > > No idea :( > Sorry, ly:tuplet-number::calc-x-offset ... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pdf changes every few compilations, although changing nothing
On Mon, Apr 10, 2017 at 7:21 AM, Thomas Morleywrote: > 2017-04-10 14:09 GMT+02:00 David Nalesnik : >> On Mon, Apr 10, 2017 at 5:36 AM, Thomas Morley >> wrote: > >>> Here the best minimal I can come up with: >>> >>> \version "2.19.60" >>> >>> tst = { >>> \override TupletBracket.stencil = >>> #(lambda (grob) >>>(let* ((orig (ly:grob-original grob)) >>> (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) >>> '())) >>> (tuplet-number (ly:grob-object grob 'tuplet-number))) >>> (if (or (and (pair? siblings) >>> (equal? grob (car siblings))) >>> (null? siblings)) >>> (ly:grob-set-property! tuplet-number 'X-offset 0)) >>> (ly:tuplet-bracket::print grob))) >>> } >>> >>> %%{ >>> \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } >>> %} >>> %%{ >>> \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } >>> %} >>> >>> >> >> I notice the same variability with 2.19.56 and 2.18.2. I'll see if I >> can figure out more. > > > Hi David, > > many thanks for caring. > > I meanwhile found using 'after-line-breaking and setting the final > stencil via ly:grob-set-property! ensures stable behaviour. > > Nevertheless I stay highly interested why this happens during a direct > stencil-override. > Here's an even more minimal example: tst = \override TupletBracket.stencil = #(lambda (grob) (let ((tuplet-number (ly:grob-object grob 'tuplet-number))) (ly:grob-set-property! tuplet-number 'X-offset 0) (ly:tuplet-bracket::print grob))) %%{ \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } %} %%{ \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } %% It's strange -- it seems that the value of ly:tuplet-bracket::calc-x-offset is used sometimes regardless of the ly:grob-set-property! and there's no predictability to it. No idea :( -David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pdf changes every few compilations, although changing nothing
2017-04-10 14:09 GMT+02:00 David Nalesnik: > On Mon, Apr 10, 2017 at 5:36 AM, Thomas Morley > wrote: >> Here the best minimal I can come up with: >> >> \version "2.19.60" >> >> tst = { >> \override TupletBracket.stencil = >> #(lambda (grob) >>(let* ((orig (ly:grob-original grob)) >> (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) >> '())) >> (tuplet-number (ly:grob-object grob 'tuplet-number))) >> (if (or (and (pair? siblings) >> (equal? grob (car siblings))) >> (null? siblings)) >> (ly:grob-set-property! tuplet-number 'X-offset 0)) >> (ly:tuplet-bracket::print grob))) >> } >> >> %%{ >> \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } >> %} >> %%{ >> \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } >> %} >> >> > > I notice the same variability with 2.19.56 and 2.18.2. I'll see if I > can figure out more. Hi David, many thanks for caring. I meanwhile found using 'after-line-breaking and setting the final stencil via ly:grob-set-property! ensures stable behaviour. Nevertheless I stay highly interested why this happens during a direct stencil-override. Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pdf changes every few compilations, although changing nothing
On Mon, Apr 10, 2017 at 5:36 AM, Thomas Morleywrote: > Hi all, > > with the code below I experienced some pretty strange behaviour. > > The visual output changes every few compilations, although I changed > _nothing_!! > In average two times in 10 compilations. > > > Furthermore: > While uncommenting the second example things change again: > First example prints correct, second always wrong. > Then commenting first example causes always correct output for the second. > > > I use self-compiled 2.19.60 from > commit 777ce245ecf9041a98d977f017c10b4edabaec04 > Author: Phil Holmes > Date: Mon Apr 10 08:28:15 2017 +0100 > > Release: bump VERSION. > > > I'm aware there were some recent changes to the bracket code and the > dependencies of TupletBracket/TupletNumber. > Admittedly my own code is a brute-force override. Something wrong > there or with the recent changes? I strongly doubt this. The changes I made to any bracket code this touches are purely organizational. On Mon, Apr 10, 2017 at 6:20 AM, Thomas Morley wrote: > 2017-04-10 12:36 GMT+02:00 Thomas Morley : >> Hi all, >> >> with the code below I experienced some pretty strange behaviour. >> >> The visual output changes every few compilations, although I changed >> _nothing_!! >> In average two times in 10 compilations. > >> Also, my code is not a minimal example, sorry for that, I keep trying >> to reduce it. > > > Here the best minimal I can come up with: > > \version "2.19.60" > > tst = { > \override TupletBracket.stencil = > #(lambda (grob) >(let* ((orig (ly:grob-original grob)) > (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) > '())) > (tuplet-number (ly:grob-object grob 'tuplet-number))) > (if (or (and (pair? siblings) > (equal? grob (car siblings))) > (null? siblings)) > (ly:grob-set-property! tuplet-number 'X-offset 0)) > (ly:tuplet-bracket::print grob))) > } > > %%{ > \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } > %} > %%{ > \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } > %} > > I notice the same variability with 2.19.56 and 2.18.2. I'll see if I can figure out more. Best, David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pdf changes every few compilations, although changing nothing
2017-04-10 12:36 GMT+02:00 Thomas Morley: > Hi all, > > with the code below I experienced some pretty strange behaviour. > > The visual output changes every few compilations, although I changed > _nothing_!! > In average two times in 10 compilations. > Also, my code is not a minimal example, sorry for that, I keep trying > to reduce it. Here the best minimal I can come up with: \version "2.19.60" tst = { \override TupletBracket.stencil = #(lambda (grob) (let* ((orig (ly:grob-original grob)) (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '())) (tuplet-number (ly:grob-object grob 'tuplet-number))) (if (or (and (pair? siblings) (equal? grob (car siblings))) (null? siblings)) (ly:grob-set-property! tuplet-number 'X-offset 0)) (ly:tuplet-bracket::print grob))) } %%{ \new Staff { \tst \tuplet 1/1 { \repeat unfold 30 c'1 } } %} %%{ \new Staff { \tst \tuplet 1/1 { c'1 c'1 c' c' c' } } %} Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pdf changes every few compilations, although changing nothing
2017-04-10 12:36 GMT+02:00 Thomas Morley: > Hi all, > > with the code below I experienced some pretty strange behaviour. > > The visual output changes every few compilations, although I changed > _nothing_!! > In average two times in 10 compilations. Forgot the attachments. Cropped pngs demonstrating it. atest-54-2.png is correct atest-54-1.png wrog Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
pdf changes every few compilations, although changing nothing
Hi all, with the code below I experienced some pretty strange behaviour. The visual output changes every few compilations, although I changed _nothing_!! In average two times in 10 compilations. Furthermore: While uncommenting the second example things change again: First example prints correct, second always wrong. Then commenting first example causes always correct output for the second. I use self-compiled 2.19.60 from commit 777ce245ecf9041a98d977f017c10b4edabaec04 Author: Phil HolmesDate: Mon Apr 10 08:28:15 2017 +0100 Release: bump VERSION. I'm aware there were some recent changes to the bracket code and the dependencies of TupletBracket/TupletNumber. Admittedly my own code is a brute-force override. Something wrong there or with the recent changes? Also, my code is not a minimal example, sorry for that, I keep trying to reduce it. \version "2.19.60" \paper { ragged-right = ##t } tst = { \override TupletBracket.stencil = #(lambda (grob) (let* ((orig (ly:grob-original grob)) (siblings (if (ly:grob? orig) (ly:spanner-broken-into orig) '())) (staff-space (ly:staff-symbol-staff-space grob)) (x-pos (ly:grob-property grob 'X-positions)) (x-length (interval-length x-pos)) ) (if (or (and (pair? siblings) (equal? grob (car siblings))) (null? siblings)) (let* ((tuplet-number (ly:grob-object grob 'tuplet-number)) (text-stil (grob-interpret-markup grob #{ \markup \vcenter "Col Whatever" #})) (text-stil-y-ext (ly:stencil-extent text-stil Y)) (text-stil-x-ext (ly:stencil-extent text-stil X)) (text-stil-x-length (interval-length text-stil-x-ext)) ;; value for y-extents of the new text-stencil. ;; ensure correlation to staff-space, some additional ;; padding is done later (half-text-y (ceiling (/ (cdr text-stil-y-ext) staff-space))) (new-text-stil (stencil-whiteout-box (ly:make-stencil (ly:stencil-expr text-stil) (ly:stencil-extent text-stil X) (symmetric-interval half-text-y)) ;; my choice: (/ staff-space 4 (if (< (+ (car x-pos) text-stil-x-length) (cdr x-pos)) (ly:grob-set-property! grob 'X-positions (cons (+ (car x-pos) text-stil-x-length) (cdr x-pos (ly:grob-set-property! tuplet-number 'X-extent empty-interval) (ly:grob-set-property! tuplet-number 'stencil new-text-stil) (ly:grob-set-property! tuplet-number 'Y-offset 0) (ly:grob-set-property! tuplet-number 'X-offset 0)); (ly:grob-suicide! (ly:grob-object grob 'tuplet-number))) ;; adjusting the values by 'staff-space' is my choice for nicer ;; paddings in X-direction. (ly:stencil-translate-axis (grob-interpret-markup grob #{ \markup \draw-squiggle-line #3 %% squiggle-length #(cons (- x-length (* 1.5 staff-space)) 0) %% dest ##t %% eq-end? #}) (+ (/ staff-space 2) (car x-pos)) X))) } %%{ { \tst \set tupletFullLength = ##t \key cis \major \tuplet 1/1 { \hideNotes c1 c1 c1 c1 \repeat unfold 30 c'1 s1*20 r2 \unHideNotes } c'2 c'1 } %} %{ { \tst \set tupletFullLength = ##t \tuplet 1/1 { c'1 c'1 c' c' c' } } %} Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add a \voicify command (issue 320820043 by d...@gnu.org)
On 2017/04/09 20:30:45, dak wrote: Fix the error behavior, rename \voicify to \voices Error handling is nice now. { \voices 1 << e''2 \\ a \\ c'' \\ a' >> \voices 1,2 << e'' \\ a \\ c'' \\ a' >> \voices 1,2,3 << e'' \\ a \\ c'' \\ a' >> } returns appropriate warnings. The visual output is another pointer for the user that something is wrong. I'd say we do the documentation issue (as mentioned earlier) in a new issue. LGTM https://codereview.appspot.com/320820043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel