On 7/14/09 2:15 PM, "Mark Polesky" <markpole...@yahoo.com> wrote:
>
>
> 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.h
> tml
>
> 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?
This is well-defined. If you do a \displayMusic of your expression, you'll
see that the
procedure gets put into the parse tree.
(make-music
'EventChord
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'force-accidental
#t
'pitch
(ly:make-pitch -1 0 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'tweaks
(list (cons (quote stencil) color-accidental))
'force-accidental
#t
'pitch
(ly:make-pitch -1 2 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'force-accidental
#t
'pitch
(ly:make-pitch -1 4 0))
(make-music
'SlurEvent
'span-direction
1)))
So color-accidental is going to get evaluated and the result passed as the
stencil of the note.
>
> 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?
If you look at the IR, you'll see three dummy grob properties that are used
to trigger callbacks.
What if a property like tweak-callback were added, whose job is just to
trigger the grob callback necessary for what you want to do?
Then you could have
\relative {
<c! \tweak #'tweak-callback #color-accidental e! g!>
}
I think you could have multiple calls to #'tweak-callback, because
all of the tweaks are stored in a list, and would all be executed.
\displayMusic
\relative {
<c
\tweak #'color #red
\tweak #'color #yellow
d>
}
gives
(make-music
'RelativeOctaveMusic
'element
(make-music
'SequentialMusic
'elements
(list (make-music
'EventChord
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'pitch
(ly:make-pitch 0 0 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'tweaks
(list (list (quote color) 1.0 0.0 0.0)
(list (quote color) 1.0 1.0 0.0))
'pitch
(ly:make-pitch 0 1 0)))))))
Personally, I think this is a cool idea!
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
