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