On 5/9/09 2:44 PM, "Neil Puttock" <n.putt...@gmail.com> wrote:
> 2009/5/9 Carl D. Sorensen <c_soren...@byu.edu>:
>
>> Similar to the Bass_Figure_engraver, I don't think I want to use
>> ASSIGN_EVENT_ONCE (), because even if I have polyphonic rests, I just want
>> one N.C. symbol.
>
> << { r4 } { r8 r } >>
>
> will result in two no-chord symbols unless you assign it once.
Oh, OK. I guess I misunderstood the Bass_figure_engraver.
>
>> No, I'm proposing that the N.C. markup would be a ChordName grob. When I
>> look at Chord_name_engraver::process_music, the markup is added to the
>> ChordName grob. If it's a rest, I'd just add the N.C. markup, instead of
>> the ChordName markup.
>
> What I meant was: would you use the chord name function to return the
> `N.C.' markup to the engraver before it creates the ChordName (so
> noChordSymbol would be read inside the function, rather than directly
> in the engraver)?
>
> I favour reading it directly in the engraver, even though all the
> other properties (apart from chordChanges) are accessed by the
> formatting function.
I had planned on returning from the engraver before even getting to the
chord name function. I expect to not call the chord name function when
processing a rest. As you do, I favor reading it directly in the engraver;
no sense going off to the chord-name function, IMO.
>
>> I still want to set a symbol setting last_chord_ as a rest, because if
>> chordChanges is true, I want to have a chord name printed following a NC,
>> even if it's the same as the previous chord. And I don't want to NC printed
>> twice for successive rests. Hence, I need to have last_chord_ set to
>> something to indicate a rest -- and I can't use chord pitches because there
>> aren't any for the rest.
>
> I don't think this would be a problem, since last_chord_ would be '(()
> ()) if the previous ChordName is generated from a rest event.
Except that I had planned to never get to that part of the engraver. I'd
handle rests first and just return.
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
