Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein <craig.dabelst...@gmail.com>: >Thanks Urs, > >And you put the "\include annotate" code in the main-init.ily file? >
Yes, and any similar code like the include of global-defs.ily etc. too. Urs >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
