Lower case minor chords, do-re-mi chord naming

• Jun 14, 2013 - 23:25

I'm considering implementing these features, asked for by various users over the past couple of years. Would appreciate any guidance on how people would expect it to work. Eg, for the lower case option, should it apply to diminished chords as well? For the do-re-mi option, are those normally capitalized? Is the seventh note in that sequence more commonly spelled "Si" or "Ti" in the countries that expect chords to be labeled this way?


Comments

Major chors have a capital letter (followed by b or #, if needed), minor chords a lower case letter (followed by # or b if needed) followed by an m. Noching else changes, dim, 7, whatever follows.

Instead of b and # it could also (and maybe should? I think lower case minor chord namers are a plain German phenomenon and as such b and # are not used.) be "es" and "is"

F# = Fis
F# = fism
Fb = Fes
Fbm = fesm
...
A# = Ais, but Ab = As (not Aes)
E# = Eis, but Eb = Es (not Ees)

(you may want to check my notenames plugin, which has translations)

In reply to by Jojo-Schmitz

You might want to check Lilypond options in this domain http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Displaying-ch…

For Do, Re, Mi, I never saw Ti used instead of Si in France. The Case depends on the publisher, it will be hard to find a common ground.
http://lymoc.pagesperso-orange.fr/part3/lam1.gif is using DO RE MI FA. Others are using Do, Re, Mi, etc... I think I never saw do, re, mi.

In reply to by Jojo-Schmitz

Lower case minor chords are used outside Germany, but it's good to know they are also used there - so German versus lower cases is not either / or. That is, I guess I shouldn't use radio buttons there. And yeah, I guess we need to support "is" and "es". I wonder if Germans ever use "dur" and "moll", or if musicians in any other countries use native-language abbreviations?

I still am not quite sure from your post about diminished chords - is it Cdim or cdim? I assume the rule is, augmented chords, dominant seventh chords, and anything with a major third is capital, anything with a minor third is lower case.

The LilyPond reference is helpful, but not complete enough to answer all these questions.

Lasconic, you also recently mentioned someone expressing the desire to include natural signs in chord names. I wonder if this was meant to happen automatically if the root or bass note is non-diatonic, or if it should require the user to explicitly type something - say, "Em/Gn" to get a an E minor chord with an G natural in the bass?

One thing I can foresee already - whatever I come up with, someone somewhere will have a case not covered :-).

My current thinking is to handle as much as is reasonable via checkboxes and radio buttons in the General Style / Chordname dialog. But I think I will also add a couple of enhancements to the chord description file mechanism to make it easier to further customize things. So worst case is people would need a customized chord description file in addition to option settings in order to get what they want in some cases. The enhancements I have in mind will actually simplify the default version as well.

In reply to by David Bolton

I don#t know much about music theory in general or chords in special. I only see minor chords wriiting in lowercase, followed by a m and major chords in caplulates. If a diminished chord is not a minor one and not a major either, I wouldn't know how to spell it and probabyl would use upper case.

In reply to by Jojo-Schmitz

Fwiw, a major chord is 1-3-5 (C-E-G). Minor is 1-b3-5 (C-Eb-G). Diminished is 1-b3-b5 (C-Eb-Gb). The usual convention in theory textbooks when representing chords with Roman numerals is to use lower caser for both minor and diminished chords, presumanly because both include b3. Eg, in the key of F, and Af major chord is "I", a G minor chord is "ii", and an E diminished chord is "viio". So I'd really need to see convincing proof - in the form of actual examples from known publishers - that diminished chords when using the "lower case" option should be represented as anything other than co (or cdim).

In reply to by [DELETED] 5

My read from the translated version of that discussion is that the OP wanted this feature because he/she was accustomed to using natural signs, but didn't have any particular reason for doing so and didn't realize that this is not at all standard.

So I'm inclined to not worry about it for now.

In reply to by Jojo-Schmitz

One other thing - I did see the note about German naming for Ab and Eb being As and Es rather than Aes and Ees. Makes sense, and I do see other precedent for that - but I also see references that make no mention of this and do show Aes and Ees. How universal is the use of As and Es in Germany? I don't currently implement this, and it would be kind of an ugly hack to make it work, but if that's what's really expected, then so be it.

In reply to by Jojo-Schmitz

OK, good to know. So I take that to mean, users would never try to *type* Aes or Ees. Are the usual flat and sharp signs just never used in this context? Do you think it would be reasonable to have users *type* "b" and "#" (eg, Gb, Gb) but have it *rendered* as "es" and "is" (eg, Ges, Gis), with the special casing so "As" and "Es" are rendered as such? I ask because I think it would be dangerous to allow the user to type "As" and have this be understood as Ab, since this introduces ambiguity into the parser The ambiguity is that "s" is also a valid character to start the extension part of the chord symbol (the part *after* the root), so it's not obvious until the chord symbol is completely parsed and understood whether the "s" is part of the root name or part of the extension. In particular, "Asus4" (A suspended fourth) would need to parse as A sus 4, but "Asmaj7" (A flat major seventh) would need to parse as As maj 7. The special casing required to handle this is something I'd like to avoid if possible.

Obviously, users already in 1.X have to type flat and sharp (well, "b" and "#") rather than "es" and "is". So I guess my question really is, would it be reasonable to ask them to *keep* typing "b" and "#"? And if so, would they be just as happy having it continue to be rendered as flat and sharp, or would they be pleasantly surprised to see this automatically converted to "es" and "is"?

In reply to by Marc Sabatella

I've added support for "As" and "Es". You can actually type these and it will be recognized accordingly unless the next character is "u", so "Esus" works as it should (E sus, not Es us). "sus" is the only common chord symbol abbreviation that begins with "s", at least in English. Makes me nervous, but it will definitely work to type "Eb" or even "Ees" no matter what comes next.

Can anyone point me to actual published or at least reasonably trustworthy scores I can find online to demonstrate particular styles of root naming. Still some questions in mind after reading the responses here and the LilyPond documentation.

Like:

- When using lower case minor chords, and you have minor chords with a bass note different from the root, is the bass note lower case also? That is, "f#m/A" or "f#m/a"?

- LilyPond shows German convention as always being upper case for root, always lower case for bass. So, "F/a". Can anyone verify this is true in the real world?

- LilyPond also shows German naming as using "#" and "b" for root, "is" and presumably "es" for bass. So, "F#/ais". Again, can anyone verify this is true in the real world?

- LilyPond shows a French variant of do-re-mi naming that appears identical to Italian except for an accent on "Re". Worth worrying about?

In reply to by Marc Sabatella

In my pretty limited experince I haven#t come accross 'german' chords with bass notes

I have seen am for Am and fism for F#m and the likes.
I have my doubts on what Lilipond seems to suggest here, but don't have any hard and fast facts, it just that something like F#/ais doesn't make any sense to me, Fis/ais and fism/as looks more logical to me. Unfortunatly Musik notations isn't as logical as I'd like it to be ;-).
Bassnote is only a note, not a chord, right? So lower case does make sense, as upper case would denote a major chord, while a minor chords would always have the m attached.
Do I'm making some sense here?

In reply to by Jojo-Schmitz

I checked Sibelius 7. They have support for "Language" and options are
- English
- German ( -> Dis7, Des7, B (=Bb), H (=B)
- Scandinavian ( D#7, Db7, Bb, H)
- Solfeggio (Do Ré Mi) ( == french in lilypond)
- Solfeggio (Do Re Mi) ( == italian in lilypond)

Quite similar to lilypond then. But bass is capitalized in german or scandinavian.

As a reference, their chord symbols style dialog is "dizzying" according to their own manual. http://db.tt/EsU6fpOw
but I could find an option to lower case the minor chord.

Finale has also its own style : http://www.finalemusic.com/usermanuals/finale2012win/content/finale/Cho…
No Do re mi here. But some interesting variants :) like the nashville ones, or the solfeggio one, based on the current key sig, movable do style.
Lower case root and base seems to be supported on a chord symbol basis http://www.finalemusic.com/usermanuals/finale2012win/content/finale/CHD…

I'm almost to a very good place with this. One nagging issue remains. I can see that some people would like for a C minor chord to be displayed as simply "c" rather than "cm" or any other explicit abbreviation for minor. And they would doubtless expect to be able to simply *type* "c" to get that to happen. Unfortunately, this turns out to be rather easier said than done given how MuseScore represents chords. I'm not saying it's impossible, but at this point it looks more disruptive than perhaps it is worth. So, how about a compromise where you had to type something explicit to indicate that you wanted a minor chord, but it wouldn't be rendered? So you'd type, say, "c=" (a play on the common abbreviation "-"), and it would be rendered simply as "c" and understood as C minor.

EDIT: second guessing myself, maybe it's possible to kludge something together where "=" is inserted and removed automatically. Still interested in feedback...

In reply to by Marc Sabatella

The kludge allowing you to type "c" and get "c" and it understood as minor seems to work OK. This is only enabled if you explicit set the new "Lower case minor chords" option.

So here's how it works now, let me know if I've missed anything important:

In the Style / General / Chordname dialog, you can now select from three radio buttons for Root/bass: Standard, German, or Italian. Tooltips show you what they mean:

Standard: "A, Bb, B, C, C#.."
German: "A, B, H, C, Cis, ..."
Italian: "La, Sib, Si, Do, Do#, ..."

There is also a checkbox for "Lower case minor chords". This not only forces all roots to display as lower case for minor and diminished chords, but it also allows you to *enter* a minor chord as simply a lower case letter (the aforementioned kludge).

Right now, bass notes always display using capitals regardless of the setting of "Lower case minor chords" - except with the German option, where they always display lower case. Still wondering if that's right.

Variations on this are possible by customizing the chord description file. Some of the things that are known to work:

Chord entry in German style *accepts* either "b" or "es" for flat (likewise for sharp), but always renders as "es". If you'd rather it render with a flat sign, you can edit the sym declaration for "es".

If you want the French style, where Re renders with an accent, you can edit the sym declaration for "Re". You'd still *type* "Re" without the accent.

You can also get all caps DO, RE, MI, or So instead of Sol, or Ti instead of Si, by editing sym declarations.

In reply to by Marc Sabatella

Sorry, one more question: what is the best way to label the radio button that produces Do, Re, Mi naming? I have it as "Italian" right now, but plenty of countries other than Italy use this style. The syllables themselves come from Latin, so "Latin" might work. In English, I might refer to this as "Solfege" naming, but that probably doesn't make sense in countries that actually use that naming.

In reply to by Jojo-Schmitz

Not normally, no. But I'm thinking, while the term "solfege" itself might translate (actually, it's not an English word at all, and it should probably have an accent), it might not be as suggestive in a culture that uses do-re-mi note naming. In the US, the term "solfege" is a good way to suggest use of those syllables, always implies use of those syllables, because we don't use them for amything else. In a country where those syllables are used all the time, "solfege" might not carry that immediate connotation.

EDIT: the fact that both Finale and Sibelius use "Solfeggio" (the Italian term, as opposed to the French-derived "Solfege") is making me lean that way despite these reservations.

In reply to by Marc Sabatella

Quite often, the format of how a chord "should" be displayed is one of personal preference.
Each person will claim their particular own preference as being correct or the best.
In this sense, would it not be a good idea to permit this to be configurable within a certain measure (no pun intended) ?
Agreed that this might make the development a bit more difficult, but it will permit people to have what they want (or at least the closet possible), rather than "imposing" a certain style.

In reply to by Simon Giddings

The biggest change I made to chord symbols for 2.0 is to allow "what you type is what you get" for the part of the chord that comes *after* the root. So you can abbreviate major as M, Ma, Maj, ma, maj, or a triangle as you see fit, etc. Or enter alterations with or without parentheses, in any order, etc. This will a huge improvement over 1.X and this much works marvelously in the nightly builds already - see http://musescore.org/en/node/21202.

The problem is that giving the same sort of flexibility to roots is a *much* more difficult problem to solve. As one obvious example of why this is so, consider MuseScore needs to be able to change chord roots if you transpose the passage or write for a transposing instrument like many woodwind and brass instruments. It's not enough that you can type something that represents the root as you'd like to see it; MuseScore needs to understand how to change it into a different root in the same style. And that means having some very clear rules for how roots can be rendered. It's OK to have a choice of multiple sets of rules, but it's got to be something programmed in to MuseScore in advance or it won't know how to do the transposition.

The transposition aspect is really just one part of why roots are different from the rest of the chord, but hopefully it gets the point across.

So given that there needs to be a predictable set of ways for entering and rendering roots, the question is, what should those be?

My hope is that what I have done is flexible enough to cover most reasonably common cases. MuseScore will actually be able to parse and understand chord entry in the three most common style - the ones I am calling "Standard", "German", and "Solfeggio": So you pick the style closest to what you want and agree to *enter* chords in that style. If you then want them *rendered* differently (like adding the accent to "Re"), you can do so by customizing the chord description file. It's the best I can think of without completely re-inventing how things work. I suppose I could add a dialog to make it possible to do that customization from within MuseScore rather than needing to hand-edit the XML file, and could see doing that some day. But even if so, the dialog will necessarily have to impose certain restrictions / expectations on what you can actually do.

Do you still have an unanswered question? Please log in first to post your question.