David Nalesnik <david.nales...@gmail.com> writes: > Hi, > > On Mon, Jan 29, 2018 at 6:10 PM, David Kastrup <d...@gnu.org> wrote: >> David Kastrup <d...@gnu.org> 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...
Ok, the default setup with tuplet-number::calc-y-offset appears to be scm/define-grobs.scm: (Y-offset . ,ly:tuplet-number::calc-y-offset) an ordinary callback. So the problem likely is that this function must not be called more than once. Which seems fragile, to say the least. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel