Re: Anybody has a good explanation for _this_ use of grob-transformer?

2018-01-29 Thread David Nalesnik 
Hi,

On Mon, Jan 29, 2018 at 6:10 PM, David Kastrup  wrote:
> David Kastrup  writes:
>
>>>   %% no fail
>>>   \override TupletNumber.Y-offset =
>>>#(ly:make-unpure-pure-container
>>>   (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
>>>   (lambda (grob start end) 1))
>>>   \tuplet 3/2 4 {
>>> c,,8 d e f g a b c d e f g
>>> c,,8^> d e f^> g a b^> c d e^> f g }
>>> }
>>
>> Ok, this means that at pure time, ly:tuplet-number::calc-y-offset must
>> not be called at all or it will ride roughshod over the X offset.  We'll
>> get the hang of it yet.
>
> At any rate, one point of grob-transformer is that it should work for
> any kind of value/callback, and it clearly doesn't here.  So either the
> theory underlying it is wrong, or the implementation.
>


I don't have time to look into the details at the moment, just to go
by my memory, having worked on TupletNumber's interaction with kneed
beams.  The callbacks for X-offset and Y-offset are not independent.
I forget which callback calls the other.  The rationale for this
yuckiness was tuplet number/accidental collision avoidance, for which
both axes are necessary,

I don't know whether this entanglement is the culprit, but I have my
strong suspicions...

David

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

Re: Anybody has a good explanation for _this_ use of grob-transformer?

2018-01-29 Thread David Kastrup 
David Kastrup  writes:

>>   %% no fail
>>   \override TupletNumber.Y-offset =
>>#(ly:make-unpure-pure-container
>>   (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
>>   (lambda (grob start end) 1))
>>   \tuplet 3/2 4 {
>> c,,8 d e f g a b c d e f g
>> c,,8^> d e f^> g a b^> c d e^> f g }
>> }
>
> Ok, this means that at pure time, ly:tuplet-number::calc-y-offset must
> not be called at all or it will ride roughshod over the X offset.  We'll
> get the hang of it yet.

At any rate, one point of grob-transformer is that it should work for
any kind of value/callback, and it clearly doesn't here.  So either the
theory underlying it is wrong, or the implementation.

-- 
David Kastrup

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

Re: Anybody has a good explanation for _this_ use of grob-transformer?

2018-01-29 Thread David Kastrup 
Thomas Morley  writes:

> 2018-01-28 18:07 GMT+01:00 David Kastrup :
>>
>> The result is that all the beams are smashed up in the left border and
>> the tuplet numbers appear over the respective first notes.  All of which
>> seems like a seriously messed up X offset rather than the Y offset that
>> should not even have been changed.
>
> Hi David,
>
> I never got to grips with that unpure-pure stuff.
>>From IR:
> Function: ly:make-unpure-pure-container unpure pure
> Make an unpure-pure container. unpure should be an unpure expression,
> and pure should be a pure expression. If pure is omitted, the value of
> unpure will be used twice, except that a callback is given two extra
> arguments that are ignored for the sake of pure calculations.
>
> I mean, really?
> In german I'd say: Verarschen kann ich mich alleine...

Trust me: for the full level of floundering you want to engage a team.

> Granted, we have more verbose explanations in the docs (NR and CG),
> though I never really figured what's it all about ...

If I remember correctly, the pure callbacks are putative, the start/end
expressions indicate the musical columns where the current line is
broken, and the unpure callbacks are final.  So why don't they get the
start/end expressions?  No idea.  Probably that information is then
already burnt into the grob?  Mere callbacks are final.  If you have
only a single callback instead of a container, the call happens just
once and the result is cached.  An unpure/pure container avoids the
caching and recalculates each time.

I suspect that there is something wrong in this description which is
sort of what I got when asking around: personally I feel it would make
more sense if the unpure version was called at a time when linebreaks
were not known yet and the pure versions otherwise, and when there is no
unpure/pure container, the result of the first call is final and getting
cached.  Something like that (grobs also cache some results of pure
calls, but with the respective start/end call as index).

> That said, I played around a little.
> No clue if it helps you in any way but eliminated grob-tranformer and
> tried three different codings.
> The last succeeds, though I've no clue why and no clue why the others fail.
> I also made the TupletBracket always visible, messed up as well for
> the failing codings.
>
> \version "2.21.0"
>
> \relative c' {
>   \voiceOne
>   \override TupletBracket.bracket-visibility = ##t
>
>   %% fail
>   \override TupletNumber.Y-offset =
>#(ly:make-unpure-pure-container
>   (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
>   (lambda (grob start end) (ly:tuplet-number::calc-y-offset grob)))
>
>   \tuplet 3/2 4 {
> c8 d e f g a b c d e f g
> c,,8^> d e f^> g a b^> c d e^> f g }
>
>   \break
>
>   %% fail
>   \override TupletNumber.Y-offset =
>#(ly:make-unpure-pure-container
>   (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1)))
>   \tuplet 3/2 4 {
> c,,8 d e f g a b c d e f g
> c,,8^> d e f^> g a b^> c d e^> f g }
>
>   \break
>
>   %% no fail
>   \override TupletNumber.Y-offset =
>#(ly:make-unpure-pure-container
>   (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
>   (lambda (grob start end) 1))
>   \tuplet 3/2 4 {
> c,,8 d e f g a b c d e f g
> c,,8^> d e f^> g a b^> c d e^> f g }
> }

Ok, this means that at pure time, ly:tuplet-number::calc-y-offset must
not be called at all or it will ride roughshod over the X offset.  We'll
get the hang of it yet.

-- 
David Kastrup

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

Re: Anybody has a good explanation for _this_ use of grob-transformer?

2018-01-29 Thread Thomas Morley 
2018-01-28 18:07 GMT+01:00 David Kastrup :
>
> The result is that all the beams are smashed up in the left border and
> the tuplet numbers appear over the respective first notes.  All of which
> seems like a seriously messed up X offset rather than the Y offset that
> should not even have been changed.

Hi David,

I never got to grips with that unpure-pure stuff.
>From IR:
Function: ly:make-unpure-pure-container unpure pure
Make an unpure-pure container. unpure should be an unpure expression,
and pure should be a pure expression. If pure is omitted, the value of
unpure will be used twice, except that a callback is given two extra
arguments that are ignored for the sake of pure calculations.

I mean, really?
In german I'd say: Verarschen kann ich mich alleine...

Granted, we have more verbose explanations in the docs (NR and CG),
though I never really figured what's it all about ...

That said, I played around a little.
No clue if it helps you in any way but eliminated grob-tranformer and
tried three different codings.
The last succeeds, though I've no clue why and no clue why the others fail.
I also made the TupletBracket always visible, messed up as well for
the failing codings.

\version "2.21.0"

\relative c' {
  \voiceOne
  \override TupletBracket.bracket-visibility = ##t

  %% fail
  \override TupletNumber.Y-offset =
   #(ly:make-unpure-pure-container
  (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
  (lambda (grob start end) (ly:tuplet-number::calc-y-offset grob)))

  \tuplet 3/2 4 {
c8 d e f g a b c d e f g
c,,8^> d e f^> g a b^> c d e^> f g }

  \break

  %% fail
  \override TupletNumber.Y-offset =
   #(ly:make-unpure-pure-container
  (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1)))
  \tuplet 3/2 4 {
c,,8 d e f g a b c d e f g
c,,8^> d e f^> g a b^> c d e^> f g }

  \break

  %% no fail
  \override TupletNumber.Y-offset =
   #(ly:make-unpure-pure-container
  (lambda (grob) (+ (ly:tuplet-number::calc-y-offset grob) 1))
  (lambda (grob start end) 1))
  \tuplet 3/2 4 {
c,,8 d e f g a b c d e f g
c,,8^> d e f^> g a b^> c d e^> f g }
}

Cheers,
  Harm

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