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 generating a "N.C." chordname, a spacer
rest would work. Of course, there would also be a property to disable the
N.C. notation.
With this in mind, I decided to modify the chord_name_engraver to accept
both rests and notes. Searching through the internals reference, I found
only one engraver that handles both rests and notes -- the
bass_figure_engraver.
Using the bass_figure_engraver as a pattern, I decided to add some code to
lily/chord_name_engraver.cc.
I put the following code in:
IMPLEMENT_TRANSLATOR_LISTENER (Chord_name_engraver, rest);
void
Chord_name_engraver::listen_rest (Stream_event *ev)
{
new_event_found_ = true;
rest_event_ = ev;
}
I think this makes the context accept a rest event.
In bass_figure_engraver.cc, there is a start_translation_timestep that sets
rest_event_ = 0.
In chord_name_engraver.cc, there is no start_translation_timestep.
Question 1: What do start_translation_timestep and stop_translation_timestep
do? When are they called? Why do some engravers have
start_translation_timestep and some don't?
My thought was that in Chord_name_engraver::process_music, I would first
check to see if rest_event_ was != 0. If so, I'd make the markup be "N.C.",
set last_chord_ to some unique value (perhaps a scheme identifier 'no-chord,
although I'm not sure yet how to do that, but I can find it in the Guile
reference docs), set rest_event_=0, create a ChordName item and set its text
property to the "N.C." markup, and return.
If rest_event is 0, I'll just go and handle the notes as normal.
Question 2: Does this processing seem reasonable -- i.e., listen_rest sets
rest_event_ = ev, then process_music looks for a non-zero rest_event_ in
order to create a NC instead of a standard chord name?
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
