[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Nalesnik
Subject: Re: Anybody has a good explanation for _this_ use of grob-transformer?
Date: Mon, 29 Jan 2018 18:33:11 -0600


On Mon, Jan 29, 2018 at 6:10 PM, David Kastrup <address@hidden> wrote:
> David Kastrup <address@hidden> 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...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]