Re: Anybody has a good explanation for _this_ use of grob-transformer?
David Nalesnik writes: > 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... 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
Re: Anybody has a good explanation for _this_ use of grob-transformer?
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?
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?
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-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