Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)

[Graham King]

On Wed, 2015-11-11 at 18:44 +0100, Urs Liska wrote:

Am 11.11.2015 um 11:14 schrieb Graham King:

<snip>

annotate "installs" itself in the Score context, and in polymetric
scores the timing-translator has to be removed from that context.

So to approach the issue one would have to remove \annotationProcessor
from the Score context and "consist" it in another context.

I don't know what would happen if it would be added to more than one
context (I can't really imagine it would work).
What would probably work *in principle* is adding that to the context
Kieren would take as the "master" context.

This passeth my understanding. 

Mine too :-) That's why I would like you to simply try it out ...

Best
Urs

I'll play with contexts in the morning.  Thanks again.

I assume (can't test currently) that any annotation would then get the
barnumber of the master context and the partial measure calculated from
there. Of course this wouldn't give very useful results but it would be
interesting to check out anyway ...

Good luck
Urs

> I hope I'm making a valid test: Had a bit of trouble integrating
> ScholarLy with a short test score, so I just plugged the \include
> statements and a \criticalRemark stanza into the
> Isaac_Confessoribus_Prosa2.ly (which is full of polyrhythms).  Will pick
> up again late tonight or tomorrow, to check that \scaleDurations is not
> messing things up.  Must dash now.
>>
>> Urs
> 

OK, I think I have a reasonable test case (attached).  Toggling the block comment at lines 66 & 79 shows the effect of moving \annotationProcessor between the Score and Staff contexts.
Alas, in Staff context, it still gives "Sorry, rhythmic position could not be determined."

OK, I looked into it a little bit (this actually *is* a good test case), and I think we're in a kind of dead end. At least I don't see a way out or any use investigating further without a very clear idea what we eventually want to achieve. Sorry.

Alas.  Many thanks for your help and support anyway.

I too have spent part of today delving into both the default bar-numbering mechanism and the Measure_counter_engraver, but both seem to be built on the same foundation, which appears not to allow for the case where the Default_bar_line_engraver has been moved into the Staff context.  But I might be a bit hard-of-thinking and hence wrong.

To the general audience on the list:
In case anyone can breathe life into the issue at some future date, my objective (perhaps refined and stated too late to be presently helpful)  is:

"to enable ScholarLy to report annotations to a polyrhythmic score in such a way that the position in the score, to which each annotation refers, can be clearly, concisely, and unambiguously stated (in the endnotes). "

To that end, I have assumed that bar-numbering for polyrhythmic music is required, even at the expense of both a non-standard approach and the possible need for manual intervention at a late stage of score preparation.  I believe, in any case, that bar numbers are generally helpful to performers, at least among those with whom I work.  At risk of turning this paragraph into a manifesto, let's add: It is true that Renaissance music had no regular barlines, and indeed I sing it, with friends, from facsimile editions in which we have to rely on the signum congruentiae if everything falls apart.  However, in modern times most singers require modern notation, and tackle a far larger repertoire of polyphony on (arguably) less rehearsal than our fifteenth- and sixteenth-century forebears.  So we need all the navigational help we can get.  As for the polyrhythmic modern editions that cause the present difficulty: part of the point is to help preserve the clos est possible link to the original mensuration and proportion, and thereby to mitigate the inappropriate rhythmic straightjacket of the modern barlines.

So, for the time being, I'll continue to add ScholarLy annotations to the source, against the day when the software might be able to process them.  But I'll take the log output, add a manually-derived bar number, and publish the result in a manually-maintained \markup block.

best regards
-- Graham

The "error" message is produced when formatting an annotation for export, and actually is a workaround for a situation that would otherwise crash annotate: The "rhythmic-location" that is present in the annotation pretends to be (0 0/0). From my source comments this seems to be a "workaround for a problem that sometimes the paperColumn gets lost along the way" - and I must say that I'm completely at a loss here. And as we don't really know what we're after I don't think it makes sense to really dive into this.

Except if David Nalesnik (who has written major parts of this) would take on the challenge. If you do, David, I'll give you the pointers where the stuff is sitting.

Best
Urs

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user