Re: question about overrides within repeats

[David Kastrup]

Werner LEMBERG  writes:

>> Well, System::post_processing ends by creating the stencils of a
>> system in reverse order.  That's probably not helping.
>
> A bug?

No, there is no guaranteed order of stencilization.  But making stuff
more random gratuitously is still going to annoy people.

-- 
David Kastrup

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 2:44 PM, David Kastrup  wrote:

> Thomas Morley  writes:
>
> > Though, why it is that arbitrary?
> >
> > Look at this variation and the attached image:
> >
> > \version "2.19.29"
> > #(define test-nmbrs
> >   (let ((nmbrs (circular-list 1 2 3 4)))
> > (lambda (grob)
> >   (let ((n (car nmbrs)))
> > (set! nmbrs (cdr nmbrs))
> > (grob-interpret-markup grob (number->string n))
> >
> > {
> >   \repeat unfold 8 {
> > \once \override TextScript.stencil = #test-nmbrs
> > c''4^\markup "foo"
> >   }
> > }
>
> Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
> order of grob evaluation at some point when a system is printed depends
> on the order of memory addresses.
>
> Find that point and you'll likely also have the culprit for various
> other stuff behaving non-deterministically, like what is drawn on top of
> what and other things frequently turning up in "make check".
>
>
Here's something interesting.

Setting the stencil during 'before-line-breaking or 'after-line-breaking
works for the short example that Harm provided.  In longer examples,
after-line-breaking goes astray after several lines.  Compare:

 \version "2.19.29"

#(define test-nmbrs
  (let ((nmbrs (circular-list 1 2 3 4)))
(lambda (grob)
  (let ((n (car nmbrs)))
(set! nmbrs (cdr nmbrs))
(set! (ly:grob-property grob 'stencil)
  (grob-interpret-markup grob (number->string n)))

{
  \repeat unfold 200 {
%% works:
\once \override TextScript.before-line-breaking = #test-nmbrs
%% jumbling after 3 lines:
% \once \override TextScript.after-line-breaking = #test-nmbrs
c''4^\markup ""
  }
}

%%%
In any case, the output of these variants is notably less screwed-up than
the original, where jumbling happens almost immediately.

My question would be: when does the evaluation of a grob's stencil normally
happen?  My guess is this normal evaluation is happening based on a
haphazard input, that using 'before-line-breaking and 'after-line-breaking
is forcing a later evaluation, at a time when grobs have been better
arranged by timing.

(Please understand that this is largely a guess.  I'm finding the code
incredible hard to follow.)

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

Re: question about overrides within repeats

[David Kastrup]

David Nalesnik  writes:

> My question would be: when does the evaluation of a grob's stencil
> normally happen?  My guess is this normal evaluation is happening
> based on a haphazard input, that using 'before-line-breaking and
> 'after-line-breaking is forcing a later evaluation, at a time when
> grobs have been better arranged by timing.
>
> (Please understand that this is largely a guess.  I'm finding the code
> incredible hard to follow.)

Some stencils will depend on the particular line break choices, some
not.

This code is incredibly hard to follow because the optimization problem
LilyPond has to solve leads to complex patterns of evaluating things
(and throwing a lot of them away).  And unfortunately the complexity is
distributed all over the place instead of having its code condensed into
one well-documented framework.

"well-documented" and "LilyPond code" rarely fit well into the same
sentence anyway.  But the code for this problem alone already makes it a
particularly bad area.

-- 
David Kastrup

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 4:56 PM, David Kastrup  wrote:

> David Nalesnik  writes:
>
> > The following function gives each TextScript grobs on a line a number
> based
> > on its position within the 'all-elements array.  Each line should be
> > numbered 1-20 in order, but that's clearly not the case.  There's a
> binding
> > of texts which sorts grobs by moment.  Comment that back in and the
> problem
> > disappears.
>
> Well, System::post_processing ends by creating the stencils of a system
> in reverse order.  That's probably not helping.
>
>
>
Which helps to explain why when I've tried to rewrite the measure counter
to increment the count through a closure, I get a backwards count.

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

Re: question about overrides within repeats

[David Kastrup]

David Nalesnik  writes:

> The following function gives each TextScript grobs on a line a number based
> on its position within the 'all-elements array.  Each line should be
> numbered 1-20 in order, but that's clearly not the case.  There's a binding
> of texts which sorts grobs by moment.  Comment that back in and the problem
> disappears.

Well, System::post_processing ends by creating the stencils of a system
in reverse order.  That's probably not helping.

-- 
David Kastrup

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

Re: question about overrides within repeats

[Werner LEMBERG]

> Well, System::post_processing ends by creating the stencils of a
> system in reverse order.  That's probably not helping.

A bug?


Werner

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

Re: question about overrides within repeats

[David Nalesnik]

Hi,

On Sun, Nov 22, 2015 at 3:00 PM, David Kastrup  wrote:

> Simon Albrecht  writes:
>
> > On 22.11.2015 21:44, David Kastrup wrote:
> >> Thomas Morley  writes:
> >>
> >>> Though, why it is that arbitrary?
> >>>
> >>> Look at this variation and the attached image:
> >>>
> >>> \version "2.19.29"
> >>> #(define test-nmbrs
> >>>(let ((nmbrs (circular-list 1 2 3 4)))
> >>>  (lambda (grob)
> >>>(let ((n (car nmbrs)))
> >>>  (set! nmbrs (cdr nmbrs))
> >>>  (grob-interpret-markup grob (number->string n))
> >>>
> >>> {
> >>>\repeat unfold 8 {
> >>>  \once \override TextScript.stencil = #test-nmbrs
> >>>  c''4^\markup "foo"
> >>>}
> >>> }
> >> Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
> >> order of grob evaluation at some point when a system is printed depends
> >> on the order of memory addresses.
> >>
> >> Find that point and you'll likely also have the culprit for various
> >> other stuff behaving non-deterministically, like what is drawn on top of
> >> what and other things frequently turning up in "make check".
> >>
>
>
I don't know if this has anything to do with it,  but the grob-array
'all-elements doesn't appear to be consistently sorted by moment.

The following function gives each TextScript grobs on a line a number based
on its position within the 'all-elements array.  Each line should be
numbered 1-20 in order, but that's clearly not the case.  There's a binding
of texts which sorts grobs by moment.  Comment that back in and the problem
disappears.


\version "2.19.30"

#(define (number-me grob)
   (let* ((sys (ly:grob-system grob))
  (all-grobs (ly:grob-array->list (ly:grob-object sys
'all-elements)))
  (texts (filter (lambda (elt) (grob::has-interface elt
'text-script-interface))
 all-grobs))
  ;(texts (sort texts (lambda (x y) (ly:momentstring idx)))
(loop (cdr t) (1+ idx)))

{
  \repeat unfold 10 {
\once\override NoteHead.after-line-breaking = #number-me
\repeat unfold 20 c''4^"foo"
\break
  }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 2:18 PM, David Nalesnik 
wrote:

>
>
> On Sun, Nov 22, 2015 at 2:15 PM, Thomas Morley 
> wrote:
>
>> 2015-11-22 20:49 GMT+01:00 David Nalesnik :
>> >
>> >
>> > On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:
>> >>
>> >>
>> >> > Is there any way to get the override to be reevaluated with each
>> repeat?
>> >>
>> >> No.  Written in that manner, the override is evaluated at _input_ time.
>> >> If you put it in a variable and use that variable 3 times, the colors
>> >> will be the same each time.  What you want is
>> >>
>> >> #(define test
>> >>(let ((colors (circular-list red green blue yellow darkgreen
>> magenta)))
>> >>  (lambda (grob)
>> >>(let ((color (car colors)))
>> >>  (set! colors (cdr colors))
>> >>  color
>> >>
>> >> and
>> >>
>> >>   \override NoteHead.color = #test
>> >>
>> >> That way you'll get one call per actual _grob_ since then each grob is
>> >> then initialized with the callback, and the callback is replaced by the
>> >> value when the property is first used.
>> >>
>> >
>> > OK, I get it.  I need to override NoteHead.color with a procedure,
>> rather
>> > than the evaluation of the procedure.  (And a grob callback must of
>> course
>> > have a grob argument.  Passing my original as a procedure results in an
>> > error.)
>> >
>> > Thanks so much!
>> >
>> > David
>>
>>
>>
>> Though, why it is that arbitrary?
>>
>> Look at this variation and the attached image:
>>
>> \version "2.19.29"
>> #(define test-nmbrs
>>   (let ((nmbrs (circular-list 1 2 3 4)))
>> (lambda (grob)
>>   (let ((n (car nmbrs)))
>> (set! nmbrs (cdr nmbrs))
>> (grob-interpret-markup grob (number->string n))
>>
>> {
>>   \repeat unfold 8 {
>> \once \override TextScript.stencil = #test-nmbrs
>> c''4^\markup "foo"
>>   }
>> }
>>
>>
>
Could they be processed out of left-to-right order?  Note that you get two
representatives of each number, and with \repeat unfold 80, you get 20 of
each.

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

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:

>
> > Is there any way to get the override to be reevaluated with each repeat?
>
> No.  Written in that manner, the override is evaluated at _input_ time.
> If you put it in a variable and use that variable 3 times, the colors
> will be the same each time.  What you want is
>
> #(define test
>(let ((colors (circular-list red green blue yellow darkgreen magenta)))
>  (lambda (grob)
>(let ((color (car colors)))
>  (set! colors (cdr colors))
>  color
>
> and
>
>   \override NoteHead.color = #test
>
> That way you'll get one call per actual _grob_ since then each grob is
> then initialized with the callback, and the callback is replaced by the
> value when the property is first used.
>
>
OK, I get it.  I need to override NoteHead.color with a procedure, rather
than the evaluation of the procedure.  (And a grob callback must of course
have a grob argument.  Passing my original as a procedure results in an
error.)

Thanks so much!

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

Re: question about overrides within repeats

[Thomas Morley]

2015-11-22 20:49 GMT+01:00 David Nalesnik :
>
>
> On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:
>>
>>
>> > Is there any way to get the override to be reevaluated with each repeat?
>>
>> No.  Written in that manner, the override is evaluated at _input_ time.
>> If you put it in a variable and use that variable 3 times, the colors
>> will be the same each time.  What you want is
>>
>> #(define test
>>(let ((colors (circular-list red green blue yellow darkgreen magenta)))
>>  (lambda (grob)
>>(let ((color (car colors)))
>>  (set! colors (cdr colors))
>>  color
>>
>> and
>>
>>   \override NoteHead.color = #test
>>
>> That way you'll get one call per actual _grob_ since then each grob is
>> then initialized with the callback, and the callback is replaced by the
>> value when the property is first used.
>>
>
> OK, I get it.  I need to override NoteHead.color with a procedure, rather
> than the evaluation of the procedure.  (And a grob callback must of course
> have a grob argument.  Passing my original as a procedure results in an
> error.)
>
> Thanks so much!
>
> David



Though, why it is that arbitrary?

Look at this variation and the attached image:

\version "2.19.29"
#(define test-nmbrs
  (let ((nmbrs (circular-list 1 2 3 4)))
(lambda (grob)
  (let ((n (car nmbrs)))
(set! nmbrs (cdr nmbrs))
(grob-interpret-markup grob (number->string n))

{
  \repeat unfold 8 {
\once \override TextScript.stencil = #test-nmbrs
c''4^\markup "foo"
  }
}

Cheers,
  Harm
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: question about overrides within repeats

[David Nalesnik]

On Sun, Nov 22, 2015 at 2:15 PM, Thomas Morley 
wrote:

> 2015-11-22 20:49 GMT+01:00 David Nalesnik :
> >
> >
> > On Sun, Nov 22, 2015 at 1:21 PM, David Kastrup  wrote:
> >>
> >>
> >> > Is there any way to get the override to be reevaluated with each
> repeat?
> >>
> >> No.  Written in that manner, the override is evaluated at _input_ time.
> >> If you put it in a variable and use that variable 3 times, the colors
> >> will be the same each time.  What you want is
> >>
> >> #(define test
> >>(let ((colors (circular-list red green blue yellow darkgreen
> magenta)))
> >>  (lambda (grob)
> >>(let ((color (car colors)))
> >>  (set! colors (cdr colors))
> >>  color
> >>
> >> and
> >>
> >>   \override NoteHead.color = #test
> >>
> >> That way you'll get one call per actual _grob_ since then each grob is
> >> then initialized with the callback, and the callback is replaced by the
> >> value when the property is first used.
> >>
> >
> > OK, I get it.  I need to override NoteHead.color with a procedure, rather
> > than the evaluation of the procedure.  (And a grob callback must of
> course
> > have a grob argument.  Passing my original as a procedure results in an
> > error.)
> >
> > Thanks so much!
> >
> > David
>
>
>
> Though, why it is that arbitrary?
>
> Look at this variation and the attached image:
>
> \version "2.19.29"
> #(define test-nmbrs
>   (let ((nmbrs (circular-list 1 2 3 4)))
> (lambda (grob)
>   (let ((n (car nmbrs)))
> (set! nmbrs (cdr nmbrs))
> (grob-interpret-markup grob (number->string n))
>
> {
>   \repeat unfold 8 {
> \once \override TextScript.stencil = #test-nmbrs
> c''4^\markup "foo"
>   }
> }
>
>
And \tweak produces bizarre results with the color function.  Try:

{
  \repeat unfold 50 {
\tweak NoteHead.color #test c''4
  }
}

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

question about overrides within repeats

[David Nalesnik]

Hi,

Given the following function, each time an override of NoteHead.color
occurs, a new color from the list is used:

\version "2.19.30"

#(define test
   (let ((colors (circular-list red green blue yellow darkgreen magenta)))
 (lambda ()
   (let ((color (car colors)))
 (set! colors (cdr colors))
 color

{
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
  \once\override NoteHead.color = #(test)
  c''4
}

However, when I put the override within a repeat structure, the override
only seems to happen once:

%% All darkgreen (we left off with yellow above
{
  \repeat unfold 10 {
\once \override NoteHead.color = #(test)
c''4
  }
}

Is there any way to get the override to be reevaluated with each repeat?

Thanks,
David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: question about overrides within repeats

[David Kastrup]

David Nalesnik  writes:

> Hi,
>
> Given the following function, each time an override of NoteHead.color
> occurs, a new color from the list is used:
>
> \version "2.19.30"
>
> #(define test
>(let ((colors (circular-list red green blue yellow darkgreen magenta)))
>  (lambda ()
>(let ((color (car colors)))
>  (set! colors (cdr colors))
>  color
>
> {
>   \once\override NoteHead.color = #(test)
>   c''4
>   \once\override NoteHead.color = #(test)
>   c''4

> However, when I put the override within a repeat structure, the override
> only seems to happen once:
>
> %% All darkgreen (we left off with yellow above
> {
>   \repeat unfold 10 {
> \once \override NoteHead.color = #(test)
> c''4
>   }
> }
>
> Is there any way to get the override to be reevaluated with each repeat?

No.  Written in that manner, the override is evaluated at _input_ time.
If you put it in a variable and use that variable 3 times, the colors
will be the same each time.  What you want is

#(define test
   (let ((colors (circular-list red green blue yellow darkgreen magenta)))
 (lambda (grob)
   (let ((color (car colors)))
 (set! colors (cdr colors))
 color

and

  \override NoteHead.color = #test

That way you'll get one call per actual _grob_ since then each grob is
then initialized with the callback, and the callback is replaced by the
value when the property is first used.

-- 
David Kastrup

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

Re: question about overrides within repeats

[David Kastrup]

Thomas Morley  writes:

> Though, why it is that arbitrary?
>
> Look at this variation and the attached image:
>
> \version "2.19.29"
> #(define test-nmbrs
>   (let ((nmbrs (circular-list 1 2 3 4)))
> (lambda (grob)
>   (let ((n (car nmbrs)))
> (set! nmbrs (cdr nmbrs))
> (grob-interpret-markup grob (number->string n))
>
> {
>   \repeat unfold 8 {
> \once \override TextScript.stencil = #test-nmbrs
> c''4^\markup "foo"
>   }
> }

Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
order of grob evaluation at some point when a system is printed depends
on the order of memory addresses.

Find that point and you'll likely also have the culprit for various
other stuff behaving non-deterministically, like what is drawn on top of
what and other things frequently turning up in "make check".

-- 
David Kastrup

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

Re: question about overrides within repeats

[Simon Albrecht]

On 22.11.2015 21:44, David Kastrup wrote:

Thomas Morley  writes:


Though, why it is that arbitrary?

Look at this variation and the attached image:

\version "2.19.29"
#(define test-nmbrs
   (let ((nmbrs (circular-list 1 2 3 4)))
 (lambda (grob)
   (let ((n (car nmbrs)))
 (set! nmbrs (cdr nmbrs))
 (grob-interpret-markup grob (number->string n))

{
   \repeat unfold 8 {
 \once \override TextScript.stencil = #test-nmbrs
 c''4^\markup "foo"
   }
}

Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
order of grob evaluation at some point when a system is printed depends
on the order of memory addresses.

Find that point and you'll likely also have the culprit for various
other stuff behaving non-deterministically, like what is drawn on top of
what and other things frequently turning up in "make check".



Should I open a tracker issue for that? Defect or Enhancement?

Yours, Simon

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

Re: question about overrides within repeats

[David Kastrup]

Simon Albrecht  writes:

> On 22.11.2015 21:44, David Kastrup wrote:
>> Thomas Morley  writes:
>>
>>> Though, why it is that arbitrary?
>>>
>>> Look at this variation and the attached image:
>>>
>>> \version "2.19.29"
>>> #(define test-nmbrs
>>>(let ((nmbrs (circular-list 1 2 3 4)))
>>>  (lambda (grob)
>>>(let ((n (car nmbrs)))
>>>  (set! nmbrs (cdr nmbrs))
>>>  (grob-interpret-markup grob (number->string n))
>>>
>>> {
>>>\repeat unfold 8 {
>>>  \once \override TextScript.stencil = #test-nmbrs
>>>  c''4^\markup "foo"
>>>}
>>> }
>> Well, it is exactly 2 variants of 1, 2, 3, 4 each.  I suspect that the
>> order of grob evaluation at some point when a system is printed depends
>> on the order of memory addresses.
>>
>> Find that point and you'll likely also have the culprit for various
>> other stuff behaving non-deterministically, like what is drawn on top of
>> what and other things frequently turning up in "make check".
>>
>
> Should I open a tracker issue for that? Defect or Enhancement?

We already have tracker issues for the non-determinacy of make check and
similar.

-- 
David Kastrup

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