lilypond-devel
[Top][All Lists]
Advanced

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

re: Chord names


From: rerdavies
Subject: re: Chord names
Date: Fri, 17 May 2002 21:18:41 -0400

> You state "dim/Ø" - but I don't think that ANYBODY conciders dim and Ø
> the same chord: Ø is by everybody I know concidered a half-diminished
> seventh, and dim is not. (correct me if I'm wrong).

Ooops. Yes. Of course. Careless mistake.

> The entire question about when to use superscript hasn't been discussed:
> I have seen the 7 in C7 both in full size, raised full size and raised
> small size.
> I like a scheme where base 3-note chords are notated in full size on the
> base line, >4note chords are notated in full size superscript and
> alterations are notated in reduced size superscript. - And hence I
> prefer the first of each of the above examples.

By 4 note chords, I assume you include unaltered chords as well? e.g.

    "Cm" (shift-up "13" (small-raised-top-aligned "9b"))

Something like that?

"C" (shift-up "Maj7" (small-raised-top-aligned "5b")   ?

k. I'll have to give that some thought. The implementation I have in mind
would have problems with that scheme. My initial impression was that if you
superscripted the "degree" of the chord (i.e. the 13 in C13(b9) ) that you
would have trouble separating the alterations, but this seems not to be the
case.

Yours is a viable notation system. And I suppose that that "C" (raised
(small "7(b5)")) is a viable notation system as well.

>   9b                    b9
> A   for the first and A   for the second.
> Notice that in alterations the alteration still goes before the number.
>
Surely that would be Ab ^ 9  and A^9b .  Also nasty cases. My personal
preference is A7b9 just to prevent the abiguity. (Not that I'm saying I'm
going to enforce this. I'm just pointing out that this is another  issue of
preference of configurability that needs to be examined.)

Do you systematically place the sharp/flat after the alteration, or is this
an exception in your case?

> Also I would like you to support square instead of sus4 - so that (with
> [] = square) one would have
>
> g-c-d: G[]
>
> g-c-d-f:  G[]7
>
> g-c-d-f-a:  G[]9
>
Noted. And duly filed away for consideration. Thanks.

Anyway. This is a problem that has all the classic hallmarks of a highly
asymetrical idiosyncratic problem from hell. I'm rather looking forward to
it. :-) Keep those nasty cases rolling in please. Better now than later.




reply via email to

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