Thanks Urs, And you put the "\include annotate" code in the main-init.ily file?
Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska <u...@openlilylib.org> wrote: > Hi Craig, > > Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: > > Urs, > > Here is a zip of the complete project. > > > Thank you, this was indeed instructive (and a nice score BTW). > > There is an issue with your set-up which I had immediately noticed and > wanted to tell you about, even before I realized you had a problem with the > annotations. I thought this would be only a matter of clean coding but > somehow this triggered your issue. > > Each annotation is generated multiple times - once for each time you > included annotate.ily. > So you should only include it once, which is what I would have recommended > anyway. > > Usually I have a set-up along these lines: > > One main-init.ily file with global definitions and includes that apply for > any file in the project. > > Two files like score-init.ily and part-init.ily. > These include main-init.ily and add specific settings to score or part > compilation > > The score file includes score-init.ily and each part file includes > part-init.ily > > This way everything is only included once, and can also be modified in one > single place. > > ### > However, this is only a case of sloppy coding and shouldn't have such > consequences, so I'll have to sort it out on "my" side. > > It seems each time you include annotate.ily you create a new instance of > the engraver. > I had thought that re-including a file would simply be re-defining > everything and be a waste of resources. But obviously when you do \consist > something multiply in a context it is actually doubled. > So I assume the function definitions (and the engraver) are redefined so > later includes simply overwrite the earlier ones. But as the engraver is > consisted in the Staff context multiple times it is also executed multiple > times. > > If you carefully inspect the console output you will notice that the > output file is rewritten multiple times too. > Interestingly the engraver uses a global annotations list, so in a first > run annotations are appended to this list and in a second run they are > finally written out. (This is done to have a list that can be sorted before > outputting). > This seems to result in all instances of the engraver adding their copy of > an annotation to the list so not only the output file is generated N times > but each annotation is produced N times. > > As said above the result is a harsh indicator of improper project > structure but the module should be able to handle that gracefully. I will > think about if I just suppress multiple includes or if I find a better way > to structure the code in the first place. > > Thanks for reporting > Best > > Urs > > > > > > On Fri Jan 30 2015 at 11:26:57 PM Urs Liska <u...@openlilylib.org> wrote: > >> >> Am 30.01.2015 um 08:16 schrieb Urs Liska: >> >> >> Am 30.01.2015 um 08:13 schrieb Philippe Massart: >> >> Probably not. I assume that hash hasn't been properly filtered. Could you >> please post the generated .inp and maybe also the LilyPond file? >> >> Urs >> >> >> These are based on the sample file included : >> >> >> Ah, OK. >> I see the offending LaTeX code, but I'll have to look into the reason why >> this is generated. >> The #f in the first line of the .inp file is the result of exporting >> something that evaluates to false. >> >> Urs >> >> >> It turns out that custom annotation types were not properly handled. >> \annotate looks up the LaTeX value in an alist dictionary, and for custom >> annotations this simply returned "#f". >> >> Pushed a fix, should work now. >> Thanks for the report. >> >> Best >> >> 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
