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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Urs Liska-3
Hi all,

I use the grob::rhythmic-location function to determine the measure position of a given grob in a score (in the scholarLY annotation engraver). However, if the measure counter is modified using \set Score.currentBarNumber this change is not reflected in the result of grob::rhythmic-location.

\version "2.19.82"

{
  \override Score.BarNumber.break-visibility = ##(#t #t #t)
  \override NoteHead.after-line-breaking =
  #(lambda (grob)
     (ly:message "Location: ~a" (grob::rhythmic-location grob)))
  c'1
  \set Score.currentBarNumber = 12
  c'1
}

This prints

Location: (1 . #<Mom 0>)
Location: (2 . #<Mom 0>)

instead of

Location: (1 . #<Mom 0>)
Location: (12 . #<Mom 0>)

Is this a bug with grob::rhythmic-location?
Is this due to some wrong use of mine (e.g. can this information only be retrieved properly at some other point in the compilation process)?
Or is there some internal offset in the measure counter (I mean: does LilyPond internally count the "real" rhythmic-location and applies an offset for printing barnumbers) that I can read out somewhere?

Thanks
Urs

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
"Urs Liska" <[hidden email]> writes:

> Hi all,
>
> I use the grob::rhythmic-location function to determine the measure position of a given grob in a score (in the scholarLY annotation engraver). However, if the measure counter is modified using \set Score.currentBarNumber this change is not reflected in the result of grob::rhythmic-location.
>
> \version "2.19.82"
>
> {
>   \override Score.BarNumber.break-visibility = ##(#t #t #t)
>   \override NoteHead.after-line-breaking =
>   #(lambda (grob)
>      (ly:message "Location: ~a" (grob::rhythmic-location grob)))
>   c'1
>   \set Score.currentBarNumber = 12
>   c'1
> }
>
> This prints
>
> Location: (1 . #<Mom 0>)
> Location: (2 . #<Mom 0>)
>
> instead of
>
> Location: (1 . #<Mom 0>)
> Location: (12 . #<Mom 0>)
>
> Is this a bug with grob::rhythmic-location?

No.  rhythmic-location uses internalBarNumber in order to get unique and
sortable results.

--
David Kastrup

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

Urs Liska-3


Am 30. September 2019 12:43:46 MESZ schrieb David Kastrup <[hidden email]>:

>"Urs Liska" <[hidden email]> writes:
>
>> Hi all,
>>
>> I use the grob::rhythmic-location function to determine the measure
>position of a given grob in a score (in the scholarLY annotation
>engraver). However, if the measure counter is modified using \set
>Score.currentBarNumber this change is not reflected in the result of
>grob::rhythmic-location.
>>
>> \version "2.19.82"
>>
>> {
>>   \override Score.BarNumber.break-visibility = ##(#t #t #t)
>>   \override NoteHead.after-line-breaking =
>>   #(lambda (grob)
>>      (ly:message "Location: ~a" (grob::rhythmic-location grob)))
>>   c'1
>>   \set Score.currentBarNumber = 12
>>   c'1
>> }
>>
>> This prints
>>
>> Location: (1 . #<Mom 0>)
>> Location: (2 . #<Mom 0>)
>>
>> instead of
>>
>> Location: (1 . #<Mom 0>)
>> Location: (12 . #<Mom 0>)
>>
>> Is this a bug with grob::rhythmic-location?
>
>No.  rhythmic-location uses internalBarNumber in order to get unique
>and
>sortable results.


Ok, I see.

How do I get the "current" bar number then, the one printed as barnumber?

Urs

>
>--
>David Kastrup
>
>_______________________________________________
>bug-lilypond mailing list
>[hidden email]
>https://lists.gnu.org/mailman/listinfo/bug-lilypond

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Urs Liska <[hidden email]> writes:

> Am 30. September 2019 12:43:46 MESZ schrieb David Kastrup <[hidden email]>:
>>"Urs Liska" <[hidden email]> writes:
>>
>>> Hi all,
>>>
>>> I use the grob::rhythmic-location function to determine the measure
>>position of a given grob in a score (in the scholarLY annotation
>>engraver). However, if the measure counter is modified using \set
>>Score.currentBarNumber this change is not reflected in the result of
>>grob::rhythmic-location.
>>>
>>> \version "2.19.82"
>>>
>>> {
>>>   \override Score.BarNumber.break-visibility = ##(#t #t #t)
>>>   \override NoteHead.after-line-breaking =
>>>   #(lambda (grob)
>>>      (ly:message "Location: ~a" (grob::rhythmic-location grob)))
>>>   c'1
>>>   \set Score.currentBarNumber = 12
>>>   c'1
>>> }
>>>
>>> This prints
>>>
>>> Location: (1 . #<Mom 0>)
>>> Location: (2 . #<Mom 0>)
>>>
>>> instead of
>>>
>>> Location: (1 . #<Mom 0>)
>>> Location: (12 . #<Mom 0>)
>>>
>>> Is this a bug with grob::rhythmic-location?
>>
>>No.  rhythmic-location uses internalBarNumber in order to get unique
>>and
>>sortable results.
>
>
> Ok, I see.
>
> How do I get the "current" bar number then, the one printed as barnumber?

It's not recorded in general grobs.  If you say you need in in
scholarLy, it sounds like a bar number subject to repetition and gaps is
not particularly useful for identification purposes anyway.

--
David Kastrup

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

Urs Liska-3
30. September 2019 13:09, "David Kastrup" <[hidden email]> schrieb:

> Urs Liska <[hidden email]> writes:
>
>> Am 30. September 2019 12:43:46 MESZ schrieb David Kastrup <[hidden email]>:
>>> "Urs Liska" <[hidden email]> writes:
>>
>> Hi all,
>>
>> I use the grob::rhythmic-location function to determine the measure
>>> position of a given grob in a score (in the scholarLY annotation
>>> engraver). However, if the measure counter is modified using \set
>>> Score.currentBarNumber this change is not reflected in the result of
>>> grob::rhythmic-location.
>>
>> ...
>>
>> Is this a bug with grob::rhythmic-location?
>>> No. rhythmic-location uses internalBarNumber in order to get unique
>>> and
>>> sortable results.
>>
>> Ok, I see.
>>
>> How do I get the "current" bar number then, the one printed as barnumber?
>
> It's not recorded in general grobs. If you say you need in in
> scholarLy, it sounds like a bar number subject to repetition and gaps is
> not particularly useful for identification purposes anyway.

Well, there may be two different applications for the barnumer in play here. An annotation includes a reference to the position, so it can say "in m. 23, 3rd beat, violin2" - and that measure is expected to be the measure that will also be printed rather than an internal counter.
But even if the grobs themselves only record that "natural" position I can't imagine there's no way to get to the barnumber of a given note column (maybe that's better than a grob itself) as seen by Score.currentBarNumber and printed by the bar number engraver.

Urs

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

Davide Liessi-2
In reply to this post by Urs Liska-3
What about introducing a new grob property containing the _printed_
bar number and the measure position?
Unless, of course, there is already a way to retrieve the desired information.

With the attached patch, the input file

\version "2.19.82"
{
  \override Score.BarNumber.break-visibility = ##(#t #t #t)
  \override NoteHead.after-line-breaking =
  #(lambda (grob)
     (ly:message "Internal location: ~a" (grob::rhythmic-location grob))
     (ly:message "Printed location: ~a" (grob::printed-rhythmic-location grob)))
  c'1
  \set Score.currentBarNumber = 12
  c'1
}

has the following output:

[...]
Internal location: (1 . #<Mom 0>)
Printed location: (1 . #<Mom 0>)
Internal location: (2 . #<Mom 0>)
Printed location: (12 . #<Mom 0>)
[...]

Best wishes.
Davide

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond

0001-Add-printed-rhythmic-location-grob-property.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Davide Liessi <[hidden email]> writes:

> What about introducing a new grob property containing the _printed_
> bar number and the measure position?
> Unless, of course, there is already a way to retrieve the desired information.

Well, you could keep track of the internalBarNumber/barNumber relation
with an engraver.

--
David Kastrup

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

Urs Liska-3
In reply to this post by Davide Liessi-2
Hi David,

thank you for looking into it. Unfortunately I don't really see how that works from the diff.
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?

Urs

3. Oktober 2019 21:07, "Davide Liessi" <[hidden email]> schrieb:

> What about introducing a new grob property containing the _printed_
> bar number and the measure position?
> Unless, of course, there is already a way to retrieve the desired information.
>
> With the attached patch, the input file
>
> \version "2.19.82"
> {
> \override Score.BarNumber.break-visibility = ##(#t #t #t)
> \override NoteHead.after-line-breaking =
> #(lambda (grob)
> (ly:message "Internal location: ~a" (grob::rhythmic-location grob))
> (ly:message "Printed location: ~a" (grob::printed-rhythmic-location grob)))
> c'1
> \set Score.currentBarNumber = 12
> c'1
> }
>
> has the following output:
>
> [...]
> Internal location: (1 . #<Mom 0>)
> Printed location: (1 . #<Mom 0>)
> Internal location: (2 . #<Mom 0>)
> Printed location: (12 . #<Mom 0>)
> [...]
>
> Best wishes.
> Davide
>
> _______________________________________________
> bug-lilypond mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

Davide Liessi-2
Il giorno sab 5 ott 2019 alle ore 16:29 Urs Liska
<[hidden email]> 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

_______________________________________________
bug-lilypond mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
Davide Liessi <[hidden email]> writes:

> Il giorno sab 5 ott 2019 alle ore 16:29 Urs Liska
> <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-lilypond