[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grob::rhythmic-location and \set Score.currentBarNumber
From: |
Davide Liessi |
Subject: |
Re: grob::rhythmic-location and \set Score.currentBarNumber |
Date: |
Sun, 6 Oct 2019 15:07:51 +0200 |
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).
Best wishes.
Davide