Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ...
Originally I had \include "part-init.ily" \include "../Notes/flute.ily" On Tue Feb 03 2015 at 9:51:03 AM Urs Liska <u...@openlilylib.org> wrote: > Hi Craig, > > it's like I expected (and not related to \anntoate): > > > Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: > > Hi Urs, > > > > Here is a zip of the complete project. There are 2 issues: > > [1] If I put "part-init.ily" and "score-init.ily" in the top-most folder > (the same folder as "main-init.ily"), lilypond returns an error -- "cannot > find "main-init-ily". > > > There are two ways how LilyPond treats include paths, relative and > non-relative. > By default LilyPond looks for \include files > - in a path relative to the location of the *compiled* file > - in a path relative to the include path (you'll get that from the error > message) > > Therefore: When you have > \include "../score-init.ily " > and in that file you write > \include "main-init.ily" > LilyPond will look for that file in the directory of the compiled file and > not in that of score-init.ily. > > There are two solutions to your problem: > > a) > exchange the second include for > \include "../main-init.ily" > b) > enter > #(ly:set-option 'relative-includes #t) > at the beginning of score-init.ily. > This will make LilyPond look in paths relative to the file where \include > is used. > > I suggest solution b) because that is usually more versatile for complex > include cascades. > (BTW I thought this was default behaviour by now ???) > > > > > [2] With the "annotate" file included in the "main-init.ily" file, the > score engraves perfectly (and produces the inp file), but the parts won't > engrave at all and return errors as they can't find the "annotate" file. > > > This is a follow-up of the first issue, if main-init.ily isn't found then > (of course) the annotate include in that file isn't done too. > So this should now be solved automatically. > > Hope it works now. > > Best > > Urs > > > > Many thanks, > > Craig > > > > > On Tue Feb 03 2015 at 4:37:44 AM Urs Liska <u...@openlilylib.org> wrote: > >> Am 31.01.2015 um 18:23 schrieb Urs Liska: >> > >> > >> > 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 >> >> >> >> Sorry, forgot about this. >> Could you please send me your _exact_ directory structure?. Including >> being completely accurate about dots and hyphens? >> >> Urs >> >> >> >> > >> > 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 >> > >> >> >> -- >> Urs Liska >> www.openlilylib.org >> >> _______________________________________________ >> 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 >
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
