Re: grob::rhythmic-location and \set Score.currentBarNumber

[David Kastrup]

Davide Liessi <address@hidden> writes:

> Il giorno sab 5 ott 2019 alle ore 16:29 Urs Liska
> <address@hidden> ha scritto:
>> thank you for looking into it. Unfortunately I don't really see how
>> that works from the diff.
>
> Both internalBarNumber and currentBarNumber (the printed one) are
> stored as context properties in the Score context.
> With the current LilyPond, PaperColumn and NonMusicalPaperColumn grobs
> have the rhythmic-location property, which, as you know, stores the
> pair (internalBarNumber . measurePosition).
> My patch simply adds a printed-rhythmic-location property to those
> grobs, storing the pair (currentBarNumber . measurePosition), and a
> corresponding grob::printed-rhythmic-location procedure.
>
>> Does David's comment suggest that it would be possible to keep track
>> of the barnumber difference through a Scheme engraver? Or is this
>> some information that already gets lost in the C++ code, so it would
>> require an update to LilyPond itself?
>
> Given that the information is available as a context property, I
> understand from David's comment that a Scheme engraver should suffice,
> but I have no experience in writing engravers.
> However, I think that the current bar number (as seen by the player)
> is such a basic kind of information that having it directly available
> as a grob property warrants this small addition to LilyPond (unless
> there are any drawbacks I am not considering).

That isn't the current bar number as seen by the player since that is
formatted and depends on stuff like the repeat numbering scheme in
place.

-- 
David Kastrup