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
