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 <u...@openlilylib.org
<mailto:u...@openlilylib.org>> 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
lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
