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"
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
On Tue Feb 03 2015 at 10:54:36 AM Craig
Dabelstein < address@hidden>
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 < address@hidden>
wrote:
Hi Craig,
it's like I expected (and not related to \anntoate):
Am 03.02.2015 um 00:00 schrieb Craig Dabelstein:
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 < address@hidden>
wrote:
Am
31.01.2015 um 18:23 schrieb Urs Liska:
>
>
> Am 31. Januar 2015 18:14:23 MEZ, schrieb
Craig Dabelstein <address@hidden>:
>> 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 <
>> address@hidden>
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 <address@hidden>
>> wrote:
>>>
>>>>
>>>>
>>>> Am 31. Januar 2015 03:05:24 MEZ,
schrieb Craig Dabelstein <
>>>> address@hidden>:
>>>>> 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 <address@hidden>
>> 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 <address@hidden>
>>>>> 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
>>>>>>> address@hidden
>>>>>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
--
Urs Liska
www.openlilylib.org
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user
|