2016-08-03 12:52 GMT+02:00 David Kastrup <d...@gnu.org>:
>
> 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
Hi David,
many thanks for the comments, they will be very helpful once I return to this.
Back in February I stopped work on this topic, because I waited for:
2016-02-21 18:46 GMT+01:00 Craig Dabelstein <craig.dabelst...@gmail.com>:
> This is great work! It's exactly what I need but it threw me a bunch of
> errors. I'll try to put together an example to show you.
Still waiting...
And still suffering from some surgery, can't work for long at the computer.
Thanks,
Harm
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
