Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

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