Thomas Morley <thomasmorle...@gmail.com> writes:
> 2018-01-28 18:07 GMT+01:00 David Kastrup <d...@gnu.org>:
>>
>> 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
