Am 10.11.2015 um 17:39 schrieb Urs Liska:
>
>
> Am 10.11.2015 um 17:08 schrieb Graham King:
>> ... long snip ...
>>
>> I confess I'm a bit daunted by the LaTeX learning curve, and it is
>> possible that I'm not uniquely inadequate in that respect. So a
>> Lilypond-only solution would be ideal for me, and would save others
>> the prospect of learning yet-another-language.
>
> OK, on the long run I will want to have both, but actually it doesn't
> matter where to start ...
>
>> I'm brainstorming a bit here, but if, for example, ScholarLy could
>> make its annotations available as a Scheme array for metadata and
>> markup, the lilypond user could access that array in a \markup block
>> after the end of the music. Layout could then be left to the user,
>> selecting just the desired elements of data.
>>
>> The array might look something like:
>> (((author . "A.N.Other")
>> (bar . 2)
>> (beat . 1)
>> (text . "\markup { \note #"4" #1 } added")
>> ...)
>> ((author . "F.Bloggs")
>> (bar . 5)
>> ...)
>> ...))
>
> I haven't looked in the code right now, but I'm pretty sure there *is*
> such a Scheme tree structure at some point. The question is if that is
> available at the moment we'd need it.
> While parsing the input annotations are built and added to an array,
> and when parsing is finished they are processed, i.e. sorted,
> (optionally) filtered and exported. I'm not sure if a reasonable
> representation is already available when regular markup is used and
> interpreted.
>
> One thing should definitely be possible: Writing that structure out to
> a temporary file and read that in at a later moment. Maybe this would
> allow to use the data only in another bookpart? But that's something
> to be discussed with those people who know more about the process of
> collecting elements of a book.
>
Now I've looked into it *to some extent*, and it seems my assumption was
quite appropriate.
'annotate' works in two steps and has two separate engravers:
\annotationCollector is (automatically) consisted to all the staff-like
contexts. Whenever it comes across an annotation in the input it appends
an object to a global 'annotations' list.
Later \annotationProcessor (which is consisted to the Score context)
iterates over this list, applies filtering and sorting, and exports it
to the desired targets.
It is possible to access the annotations list/array from within
\annotationProcessor, and it is easy to create a command (like e.g.
\printReport) that switches of a certain processing.
But when I try to access the 'annotations' object from LilyPond input
(be it from a toplevel command before or after the score or whenever, or
from within the music) this object seems to be empty.
So I assume that it's only possible to access the information from
within the engraver and not from the user code.
This leaves two options, and I would like to get an opinion which of
these is/are possible:
a)
have that \annotationProcessor produce some markup in the current score,
presumably (starting) on a new page at the end of the score or have it
create a new bookpart consisting of such markup
b)
write out the data to a temporary file (clearly possible) for another
command. This would have to read in the data and produce the necessary
markup. Would it be possible to place such a command in a new bookpart,
i.e. have an engraver in one bookpart write out something to disk and
sos me other function in a later bookpart read that in again?
c)
as a last resort LilyPond could write the data to a temporary file and a
second command could process that data from within *another* file that
would have to be compiled separately.
This would of course be quite hacky but still avoid having to use a
second tool (LaTeX).
I'd be grateful for any opinions/suggestions/solutions.
Urs
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
