[EMAIL PROTECTED] wrote:
I understand what you mean but I tend to agree with Jan that a Much Better (tm) solution would be to add more flags to the notes produced by the current system. This way we could also keep supporting the <notes in chords> mode by making it possible to attach the flags to the notes directly.After having mostly completed a rewrite of the ChordName to pitch code, it became apparent to me that the opposite problem (converting a chord representation to pitches) is much easier. Perhaps a regrouping might be in order.
Furthermore, choices of when to use "no" and when to use "add",
<c e g d'> gives c(add 9) <c e g bes(no) d'> gives c9(no 7)
Hmm, too output-specific - imho better to use the general text-mechanism discussed below in such cases...My short list of basic operators might include: () - Literal brackets in the output.
You would also use ^ to seperate constructs... Now I don't really understand anymore...^ - superscript.
Sounds like a good idea to allow for arbitrary text-xtrings (in "quatation marks") in chords mode.On the same topic, but in a much easier vein, I would very much like to add support for "N.C"/"No Chord" to the chord engraver, although I'm not sure what the easiest way to do this is. Something to do with fielding text events? Or fielding rest requests? Either would do. My preference would be to allow arbitrary strings in the chord line (e.g. "No chord."1).
Perhaps one could also (as an alternative) use the general markup-mechanism to specify chords so that one could attach chords as scripts, insert chords in lyrics, etc...
I know that Jan says that the markup is about to change - but as long as we don't know in which way it is gonna change it is really a bit hard to comment on...
-Rune
_______________________________________________
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
