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.
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
