Xpost and Fup2 lilypond-devel
Thomas Morley <thomasmorle...@gmail.com> writes:
> Some remarks/TODOs, especially:
> Why I cannot _create_ a MultiMeasureRestText-grob via `ly:engraver-make-grob'?
> It works for TextScript ...
Do you have an example of what doesn't work?
> %% How to do?
> %% It worked with simple TextScript ...
> #(define (mmr-range-engraver context)
> "Print the range of a @code{MultiMeasureRest}, if the context-property
> @code{printMmrRange} is set @code{#t}."
> (let ((m-m-r-print '()))
> `((acknowledgers
> (multi-measure-interface
> . ,(lambda (engraver grob source-engraver)
> (if (eq? (grob::name grob) 'MultiMeasureRestNumber)
> (set! m-m-r-print
> (cons
> (cons grob (ly:context-property context 'printMmrRange))
> m-m-r-print))))))
[...]
> ,(lambda (trans)
> (let* ((timeSignatureFraction
> (ly:context-property context 'timeSignatureFraction))
> (fraction
> (/ (car timeSignatureFraction) (cdr
> timeSignatureFraction))))
[...]
> (lambda (mmr)
> (if (and (cdr mmr) (not (null? (cdr mmr))))
> (let* ((m-m-r-start
> (/ (ly:moment-main
> (grob::when (ly:spanner-bound (car mmr)
> LEFT)))
> fraction))
> (m-m-r-stop
> (/ (ly:moment-main
> (grob::when (ly:spanner-bound (car mmr)
> RIGHT)))
> fraction)))
Oh good grief, this sucks. Guess what happens with meter changes. You
need to use 'rhythmic-location rather than 'when but even then, this
only gives you the value of internalBarNumber which is fine for
calculating the total number of bars but does not help all that much
with the actual bar number labels under interesting bar numbering
schemes. There currentBarNumber is wanted.
The obvious solution is to just grab currentBarNumber (and whatever
else) off the context in the acknowledger and the end-acknowledger for
multi-measure-rests. This suffers from the slight drawback that the
end-acknowledger is currently not even getting called.
We could instead siphon off the duration, wait out the appropriate
process-music call at the correct absolute time, and then finally record
the suitable currentBarNumber at the end. Which is ugly.
So it seems to make more sense to provide end-acknowledger calls for
multi measure rests. And maybe we need to survey other spanners
proactively whether they'd warrant end acknowledger calls.
Aaaaand there is the added complication that the end range number we get
in that manner is from the measure starting _after_ the rest. And when
we are concerned about strange bar numbering schemes, just substracting
1 from the bar number might not be correct: we really need the previous
bar number. And we cannot just grab them off some
start-translation-timestep since the whole manner of compressing
multimeasure rests relies on no intermediate timesteps occuring at all.
Huh.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
