Re: Request for Comment - Chordname strategy

[Rune Zedeler]

address@hidden wrote:

> 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.

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.

> 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)


> My short list of basic operators might include:
>
> ()  - Literal brackets in the output.

Hmm, too output-specific - imho better to use the general text-mechanism 
discussed below in such cases...

> ^  - superscript.

You would also use ^ to seperate constructs... Now I don't really 
understand anymore...


> 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).

Sounds like a good idea to allow for arbitrary text-xtrings (in 
"quatation marks") in chords mode.
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