Hi Urs, I followed your advice re: file structure -- "main-init.ily" has annotate, and "part.init.ily" and "score-init.ily" include "main.init.ily".
When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find "annotate". Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska <u...@openlilylib.org> wrote: > > > 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
