lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

## Re: Color one accidental in a chord? Also, improved docs ... again!

 From: Trevor Bača Subject: Re: Color one accidental in a chord? Also, improved docs ... again! Date: Fri, 28 Nov 2008 16:02:39 -0600

On Fri, Nov 28, 2008 at 1:18 PM, Jonathan Kulp wrote:
Trevor Bača wrote:
Hi,

First off, I am once again amazed at the incremental improvement in the
docs. For example: 5.3.4 "The \tweak command". I've been working this
morning on coloring one (and only one) accidental in a chord. It seemed like
\tweak would be the way to do it. The \tweak command works, for example, in
constructions like <c' \tweak #'color #red a'>4 to adjust the color of
individual noteheads within a chord. However, I ran into the problem that
\tweak decides which grob to apply to *lexically* (ie, by the bit of input
syntax immediately following) which works great for noteheads, slurs and the
like but doesn't work for accidentals because accidentals get created
implicitly during interpretation.

So, after fiddling with \tweak for a while to color just one accidental in a
chord, I'm pretty sure that \tweak won't work but I'm still not completely
sure. "Am I thinking of things correctly? Or is there something easier that
I'm missing?" So I click over to 5.3.4 . Not only has the section been
expanded from the last time I read over it (probably more than a year ago)
and not only does it read great, there is now the following language on
explicit limitations of the command:

"Notably the \tweak command cannot be used to modify stems, beams or
accidentals, since these are generated later by note heads, rather than by
music elements in the input stream."

This is excellent. Not because I can't color a single accidental. But
instead because *the docs are explicit enough to stop me spending any
further time going down the wrong path*.

I know this seems like small point. But, to me, it is only the most
professional docs that list not only what something does do ... but also
what something *does not do*. (I'm reminded of "limitation of scope"
sections that appear in some of the best-written  software specification
docs: all software requirements docs list pages and pages of what the system
shall do, but it takes someone to go the extra mile to include writing that
points out limitations about what the system need not do.) Of course there's
something of a tradition of this in the docs in general because of the
'known limitations and bugs' sections, which are also quite useful.

So thank you to whoever edited 5.3.4. And thanks again to the entire GDP
team for the dramatic improvements in the docs generally over the last
months.

Now on to my original question.

* * *

QUESTION: is it possible to reach inside of a chord and color just one
accidental red?

\tweak isn't going to work, as is quite clear from the docs, and Trevor
(D)'s post to this thread earlier this year in April ...

http://lists.gnu.org/archive/html/lilypond-user/2008-04/msg00067.html

... makes me think that the task may not be possible at all.

Does anyone have a work-around?

I just made up a workaround for a simple example.  Maybe you can use it in more complicated situations, too.  I put the inner note of the chord in a separate voice.  To keep the notes all lined up as if they were in one voice, I put \voiceOne commands in both voices.  Just ignore the warnings about too many clashing note columns.  HTH,

Jon

\version "2.11.64"

\relative c' {

<< { \voiceOne <bes f'>1 } \\ { \voiceOne \override Accidental #'color = #blue des1 } >>

Hi Jon, hi Trevor (D),

Thanks for the suggestion. The layered voices are kinda hacky but they work successfully in my case.

There is, btw, a switch to suppress collisions in cases like this, implemented on NoteColumn ...

\new Staff <<
\override Staff.NoteColumn #'ignore-collision = ##t
\new Voice { \voiceOne <bes f'>1 }
\new Voice { \voiceOne \override Accidental #'color = #blue des'1 }
>>

... which makes the solution interpret completely cleanly.

Thank you both!

Trevor (B).

--
Trevor Bača
address@hidden

reply via email to

 [Prev in Thread] Current Thread [Next in Thread]