Re: ScholarLY - introduction and call for collaboration

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

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