It is now working ABSOLUTELY BRILLIANTLY! Thanks for all your help.
Craig On Tue Feb 03 2015 at 11:15:18 AM Urs Liska <u...@openlilylib.org> wrote: > > Am 03.02.2015 um 01:55 schrieb Craig Dabelstein: > > 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" > > > Ah yes, I did that too, but thought I needed that only for the > dynamics-def file... > > > > It is still producing an inp file for every single part though. > > > I'm not sure what you mean. > As it is the function will produce one .inp file for any compilation. So > if you compile a part it will produce a file for that part, and if you > compile the score it will compile a file with annotations for the whole > score. > > If that's not what you want (which is quite normal) you have to control > the behaviour with the configuration commands (and that's where the > multipart include set-up comes in). > > Try putting > \setAnnotationExportTargets #'("latex") in init-score.ily and > \setAnnotationExportTargets #'() in init-part.ily > (and remove that command from init-main.ily) > > HTH > > Urs > > > > 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