On 5/9/09 2:44 PM, "Neil Puttock" wrote:
> 2009/5/9 Carl D. Sorensen :
>
>> 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
2009/5/9 Carl D. Sorensen :
> 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.
> No, I'm proposin
On 5/9/09 1:58 PM, "Neil Puttock" wrote:
> 2009/5/9 Carl D. Sorensen :
>> Over the past few months, several people have asked for a "N.C." notation to
>> be part of the ChordNames context.
>>
>> It occurred to me that using r to generate a "N.C." would be logically
>> consistent -- the music
2009/5/9 Carl D. Sorensen :
> Over the past few months, several people have asked for a "N.C." notation to
> be part of the ChordNames context.
>
> It occurred to me that using r to generate a "N.C." would be logically
> consistent -- the music gets a rest, the chord name gets a "N.C.". And if a
>
Over the past few months, several people have asked for a "N.C." notation to
be part of the ChordNames context.
It occurred to me that using r to generate a "N.C." would be logically
consistent -- the music gets a rest, the chord name gets a "N.C.". And if a
user wants to put space in without gen
