lilypond-devel
[Top][All Lists]
Advanced

[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 Kastrup
Subject: Re: Anybody has a good explanation for _this_ use of grob-transformer?
Date: Tue, 30 Jan 2018 00:19:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> 2018-01-28 18:07 GMT+01:00 David Kastrup <address@hidden>:
>>
>> 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



reply via email to

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