lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Urs Liska
Subject: Re: ScholarLy and polymetric music? (bar numbering, \RemoveEmptyStaffContext)
Date: Wed, 11 Nov 2015 18:44:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0



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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]