In NR 5.3.4 "The \tweak command", it says this: 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.
http://kainhofer.com/~lilypond/Documentation/user/lilypond/The-tweak-command.html But I *am* able to abuse the notehead's stencil property to tweak the accidental: \version "2.13.2" #(define (color-accidental grob) ;; notehead stencil callback (let ((stil (ly:note-head::print grob)) (accidental (ly:grob-object grob 'accidental-grob))) (ly:grob-set-property! accidental 'color red) stil)) #(define (suppress-accidental grob) ;; notehead stencil callback (let ((stil (ly:note-head::print grob)) (accidental (ly:grob-object grob 'accidental-grob))) (ly:grob-suicide! accidental) stil)) \relative { <c! \tweak #'stencil #color-accidental e! g!> <c! \tweak #'stencil #suppress-accidental e! g!> } Questions: 1) are the results of this technique undefined? Was it just luck that these worked? 2) This seems so kludgy. I presume I can only access the NoteHead's 'accidental-grob property through its standard settings (duration-log, stem-attachment, stencil, X-offset, and Y-offset). I wish I could do something like this instead (this of course doesn't work) --- #(define (color-accidental grob) ;; notehead foo callback (let ((accidental (ly:grob-object grob 'accidental-grob))) (ly:grob-set-property! accidental 'color red) #t)) \relative { <c! \tweak #'foo #color-accidental e! g!> } This would imply that I could make up my own dummy property and it would (magically) have access to the note-head-interface internal properties. Then I wouldn't have to bother making sure I return the correct value for whatever standard setting I'm abusing (stencil in the above case). Besides, I'd want to be able to tweak that standard setting independently. As a compromise, I considered the possibility of actually implementing a 'dummy property, but I don't think that would work either, because each subsequent call to \tweak #'dummy would override the previous one (for a given note). This bizarre approach might solve a lot of problems for me, but I don't like abusing properties like this. What do you guys think? - Mark _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
