Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein <craig.dabelst...@gmail.com>: >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 > >
I may look into it in a few hours. Maybe a case for a tutorial ... >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