Re: Discuss signature for new function \annotate (new version)

[Urs Liska]

On 06/10/2013 07:16 PM, Kieren MacMillan wrote:

Hi Urs,

How would LilyPond represent barnumbers in polymetrical situations?

Not sure… 

http://www.lilypond.org/doc/v2.16/Documentation/internals/timing_005ftranslator
says currentBarNumber is a property from Timing_translator.
So in a polymetric situations there will be independent barnumbers at any given moment.

BTW: How can I read such properties in a Scheme function, i.e. determine where we are in a piece when a function is executed?
I didn't find it in the manual ...
http://www.lilypond.org/doc/v2.17/Documentation/extending/object-properties says that object properties are stored in alist-chains.
So I'm looking for an entry '(currentBarNumber . N) of the Score object.
But that doesn't help me unfortunately.

How would I write if I want something like

(define curNum Score.currentBarNumber)
?

I'm not even sure how it's done in hand engraving!
I'll look it up (in Gould, etc.) and get back to you.

That would be interesting.

I'm working on a commission right now where the piano is in a fairly constant 7/8, the voice is in 4/4 most of the time (with some 3/4 and 7/8 now and then) and the oboe is in cadenza mode; I'm not yet sure how to "number the bars", since they line up so rarely. There are section marks ("rehearsal letters"), but that's it right now.

And how would one represent them in a report (i.e. how would you refer to a specific point in the score)?

That's the big issue, I would assume: You need a way to easily pinpoint a spot in a score, "independent" of the timing going on around it.
Maybe \tag is the answer?

Or maybe just ignore us weird composers who don't always write music where the barlines are synchronized in all parts. =)

Well, if my assumption about the independent timings is right then the correct way to determine a spot in the score would be something like Context->Barnumber, where Context usually would be the Staff (or a PianoStaff or whatever subgroup of staves).
But that's why I intend to leave pinpointing to the spot in the score open to be a string that anybody can interpret in his own way.
Could be just plain text measure numbers, LaTeX shorthands, or a custom syntax of shorthands (e.g. P4S3M2 for page 4, system 3, measure 2) that will be processed and styled by some postprocessor.

The idea of lilypond-doc is to be partly parametrized, partly open. There are 'recognized' properties that will be handled and 'custom' properties that are just written out to console and a file to be processed in an arbitrary way.
So to take the example of polymetrics: (If I manage) I want to determine the Staff context and the timing information automatically. So the function will for example spit out: Staff "Piano up", measure 14. If we have a polymetric situation this "measure 14" will just be another measure than the one from an event that takes place at the same time in another staff.
But if you want to use another output scheme you can add a custom property like moment = 4'33'', print that, and just ignore the automatic values.
All you should do is treat such custom properties consistently because otherwise the entries wouldn't end up in the same list.
So actually I think there isn't an issue at all with polymetrics :-)

Urs

Cheers,
Kieren.