Re: pdf changes every few compilations, although changing nothing

2017-04-10 Thread David Nalesnik
On Mon, Apr 10, 2017 at 7:43 AM, David Nalesnik
 wrote:
> 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

2017-04-10 Thread David Nalesnik
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 :(

-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 Thread Thomas Morley
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

2017-04-10 Thread David Nalesnik
On Mon, Apr 10, 2017 at 5:36 AM, Thomas Morley  wrote:
> 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 Thread Thomas Morley
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 Thread Thomas Morley
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

2017-04-10 Thread 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.


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?

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)

2017-04-10 Thread thomasmorley65

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