Re: ScholarLY - introduction and call for collaboration

[Craig Dabelstein]

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