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 < 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
|