[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: grob::rhythmic-location and \set Score.currentBarNumber
Date: Sun, 06 Oct 2019 15:47:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]