On Sat, May 2, 2015 at 9:38 AM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:
> Hi David,
>
> > Could you clarify how you are defining \theScore here?
>
> Sorry… that was pseudocode. My actual [minimized] score code was:
>
> \score {
> \colorOverride <<
> \new Staff \someMusic
> ….
> >>
> }
>
OK! Though I am disappointed you don't have a magical way to put scores in
variables :)
>
> I’m not sure about others (Jan-Peter?), but for the edition-engraver, I
> would like to do something more like:
>
> \score {
> <<
> \new Staff \someMusic
> >>
> \layout {
> \context {
> \Score
> \consists \editionEngraver editionName
> \colorOverride
> }
> }
> }
>
>
The above code would work with the first approach, where \
markAllAlteredGrobs basically created a long series of \overrides of every
grob which might have a stencil. This involved setting the
'after-line-breaking property of all such grobs to a callback which
examined the property lists of living, breathing grob instances to see if
anything had been added to the default property list stored in the global
variable all-grob-descriptions. The idea being that the list would change
with any override.
This approach quickly got hairy.
For one thing, clefs get their 'glyph property added later on. That was
why initially all clefs got colored, even the default treble clef that you
get with { c d e f }, for example. Who knows if there are other such cases.
For another, tweaks--unlike overrides--do not result in a change to the
grob's basic property alist. To get at tweaks, it is necessary to find the
"music-cause" of the grob--i.e., find the music expression which lead
ultimately to its creation. Luckily the stream event carries a reference
to this earlier stage of processing. (BTW, there is a note somewhere in
the source that says this reference ought to be removed at some stage.)
(This method also--like the music function \colorOverride--can't get at
properties overridden in a \layout \context block. I really don't know how
to do that, and I hope that someone can give me a way!)
It occurred to me that it was more natural to simply look at the music
input. The method above tries to detect overrides by a sneaky method of
comparing property alists with default alists, bound to break down or lead
to complexities (as with the special casing of Clef.glyph). Why not just
look at the music expression for OverrideProperty, RevertProperty--there's
no mistaking those for override or revert.
Plus, it's easy to tell if it's a user override or one that happened
through \voiceOne, \voiceTwo so half the stems in the piece don't turn
green.
This would be the method you hint at below:
or
>
> \addEdition editionName 1 0/4 editionName.Score.A \colorOverride
> \score {
> <<
> \new Staff \someMusic
> >>
> \layout {
> \context {
> \Score
> \consists \editionEngraver editionName
> }
> }
> }
>
And this *should* work just fine. Except that I believe that the
editionEngraver adds the overrides outside of the music expression somehow.
Therefore, they are invisible to \colorOverrides.
(I wonder if Jan-Peter could clarify what it is that the engraver does; I'm
not familiar with the code, and fear that I've misrepresented it.)
I *would* like to figure out how to get into the \layout block to color
those overrides too. However, I'm guessing that this will have to be done
by a second function, a two-pass approach to coloring the score. And,
again, I need advice on how to write such a function :)
For people who mix overrides in the music expression and adopt at most a
moderate separation of "presentation" and "content" the function
\colorOverride[1] should work just fine. Jan-Peter could probably come up
with something easily integrated with the editionEngraver to accommodate
that more complete separation.
Whew...long email. Hope that clarifies the issues!
David
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
