Urs, Another question ... Is there a reason why "main.init.ily", "part-init.ily" and "score-init.ily" can't be in the same folder?
If I put "part" and "score" in a sub folder they can locate "main" in the folder above, however, if I put them all in the same folder I get "cannot find file main-init.ily" errors. Strange! Craig On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein < craig.dabelst...@gmail.com> wrote: > 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
