On Fri, Nov 28, 2008 at 1:18 PM, Jonathan Kulp <[EMAIL PROTECTED]>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 [EMAIL PROTECTED]
_______________________________________________ lilypond-user mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-user
