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 "../Notes/flute.ily" \include "part-init.ily" I reversed the order of these two lines and now it works perfectly. \include "part-init.ily" \include "../Notes/flute.ily" It is still producing an inp file for every single part though. Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein < craig.dabelst...@gmail.com> wrote: > 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
