lilypond-devel
[Top][All Lists]
Advanced

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

Re: Help on handling both rests and notes in one engraver


From: Carl D. Sorensen
Subject: Re: Help on handling both rests and notes in one engraver
Date: Sat, 9 May 2009 15:50:49 -0600



On 5/9/09 2:44 PM, "Neil Puttock" <address@hidden> wrote:

> 2009/5/9 Carl D. Sorensen <address@hidden>:
> 
>> 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





reply via email to

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