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: >> >> >> >> >> >> Am 09.11.2015 um 17:34 schrieb Graham King: >> >> >> >>> (This note describes an issue arising from the separate thread, >> >>> "Scholarly footnotes" [1]) >> >>> >> >>> I would like to use Urs' annotate.ily[2] to add some footnotes to an >> >>> edition of sixteenth-century polyphony. But, before investing too >> >>> much time, I need to check whether there is now a way for it to cope >> >>> with polymetric music[3]. >> >> >> >> As the discussion in this thread clearly shows this is firstly a >> >> conceptual problem. Only if it is clear what you want to achieve we >> >> can even start thinking about a solution implementation-wise. >> >> >> >> 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 (did I ever say that it is cool that I can >> inspect openLilyLib code on Github using my phone?). > Sheesh Urs! I know you're bright, but I've just had this image of your > whipping out the phone in a few bars rest, with the thought "I've just > got time to fix the earthling's problem..." :-) >> 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 >> > >> >> > > > _______________________________________________ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
