On Wed, 2015-11-11 at 09:18 +0100, Urs Liska wrote:
Am 11.11.2015 um 01:32 schrieb Graham King:
On Tue, 2015-11-10 at 22:50 +0100, Urs Liska wrote:
Am 10.11.2015 um 18:06 schrieb Graham King:
> On Tue, 2015-11-10 at 10:09 +0100, Urs Liska wrote:
<snip>
>> I'm not so sure that it will be possible to implement a solution that
>> really works automatically and is at the same time sufficiently
>> general. But you'd be in any case to create a manual solution, if
>> that's a viable approach given your material (that is: how many of
>> these annotations do you expect, will the numbering be stable or will
>> you have to expect any changes after the fact?)
> Very happy to intervene manually in bar numbering. The remainder of
> this thread is opening my eyes to the difficulty of automating that.
Just to avoid misunderstandings: What I am thinking about is an approach
where you add a custom property passing a barnumber manually to the
annotation. I don't think we'll be able to manually modify LilyPond's
idea of barnumbers.
Thanks for the clarification. I don't think it's a problem so long as two aspects of the workflow are covered:
1: during the preparation of the score, we'll need to be able to capture the issues and display them somehow, and relate each issue to its place in the score. This does not need barnumbers as we still have source code (and maybe an IDE). Almost certainly not a problem.
The annotations do have their connection to the originating objects, regardless of being able to determine a proper musical position. The messages printed to the console are linked to the input position, so clicking on a message will move the cursor to the annotation, and the objects are colored in the score so you have the same navigation available through point-and-click.
If you want to have something readable available I would suggest the following:
(temporarily) move the \annotationProcessor from the Score to another context. Choose the one that you consider the "master" context (as per Kieren's concept). Then the annotations *should* (not tested yet) get the master context's barnumber and a partial measure starting from that context's last barline.
2: Bar numbers need to crystallise only at the publication stage.
>> We would surely be able to taylor a solution using either a custom
>> annotation type or a custom annotation property.
Now I get it. The human being at the keyboard tells ScholarLy the bar number. I'm happy with that. I might add a git hook to flash at me a message: "Now go back and adjust the bar numbers in the annotations!" :-) Seriously: It will very rarely be an issue.
Well, actually I would then do that as one single step towards the end of the edition process, when you're sufficiently sure that neither the music nor your bar numbering scheme will change anymore.
It is a compromise, but so far I don't see a solution that could be completely automated (due to the conceptual difficulties, not the implementation).
>>
>> As a start you could try out and tell us what LilyPond/ScholarLY do by
>> default if used in polymetric scores. I *assume* that LilyPond
>> maintains individual bar numberings for each context
> Yes, that appears to be the case.
>> and that ScholarLY will just use the "local" barnumbers, without even
>> knowing there's an issue. But it would be nice if you could verify that.
> Scholarly gives the message: "Sorry, rhythmic position could not be
> determined."
OK, I see why this happens
<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."
|
scholarly2.ly