Davide Liessi <davide.lie...@gmail.com> writes: > Il giorno sab 5 ott 2019 alle ore 16:29 Urs Liska > <li...@openlilylib.org> 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 _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
