Detailed proposal for improved chord symbol handling
As discussed in http://musescore.org/en/node/17469, I have been working on a proposal for improving the handling of chord symbols. In particular, to make it easier to customize how chord symbols are typed and rendered. Miwarre has agreed to help implement my design.
I ended up combining some of the best elements of what I had proposed last year with what I was suggesting more recently to come up with something I am very excited by - something that should be great for usability but also pretty low risk to implement. The gist of it is:
1. MuseScore will automatically recognize all common variations on chord symbol spelling. So you will be able to type Cmi7, Cm7, C-7, or Cmin7, and MuseScore will recognize it as a minor seventh chord - no special setup or customization required to get this behavior.
2. Regardless of how you happen to have typed your chord symbol, MuseScore will render it using the currently selected chord symbol style. So regardless of whether you type Cmi7 or Cm7, if your chord symbol style says minor seventh chords should be rendered as Cm7, that's what you'll get.
Sibelius does this much and it seems to work well for them. And it appears this will actually be quite straightforward to implement. It will require no changes to the score format and only a very minimal addition to the chord description file format . The trickier part will be:
3. A facility will be provided to make it easy to customize your chord symbol style preferences. For example, a dialog box with radio buttons to select between "mi", "min", "m", and "-" as the abbreviation for minor, and similarly for major, diminished, etc. There will also be more advanced options for specifying the amount by which to superscript the "7" in seventh chords, the relative size of the chord root versus the "mi", and a host of other details. The chord style editor that Werner already added for 2.0 will also be retained. Whereas my new facility lets you specify default appearance for all minor seventh chords generally, the existing facility allows you to tweak each specific type of minor seventh chord (mi7b9, mi7b13, mi9, mi11, mi13, etc) individually. Together, they should pretty much eliminate the need for hand-editing of XML files in order to customize the appearance of chord symbols.
I have this spec'ed out as well as I can, but I won't be surprised if #3 turns out to be a bit harder than I anticipated. So, no guarantees as to when that might be finished.
But the chord parsing that allows you to type virtually anything and have it automatically converted to your preferred style looks to be much simpler and worth doing even without the chord symbol style customization facility, so we'll tackle that first.
Here is the design document I wrote up:
https://docs.google.com/document/d/1Q7LXHDSkQb70xmcyquFSiSv_lGbOXMDwzn_…
If you're expecting this to be concise, probably haven't read many of my writings :-) But while there is lot to the design, and implementing it will involve a fair amount of new code, the bulk of it will probably be in that chord symbol style customization facility, which means it won't affect anyone not explicitly using that aspect of it.
Comments
2 thinks I didn't notice in the proposal:
1. A chord should be major by default, a simple "A" is A major" (and capitilal, see below)
2. A common notation I see often, here in Germany at least, is that minor chords are in lower case (with an m attched, eg. "am", could this me made an alternative spelling?
3. In MuseScore code a chord symbol is called 'harmony", not sure whether that's a better term than 'Chord Symbol"?
Or maybe the code should rename it, to avoid confision?
In reply to 2 thinks I didn't notice in by Jojo-Schmitz
True, a chord is major by default. There are a number of semantic details I did not explicitly build in to the grammar I laid out but would need to account for as we built the internal representation while parsing. i will add a note to this effect.
Thanks for the reminder on the convention of lower case minor chords. I agree it would be good to add support for that. I will build that in.
Using the term "harmony" internally is fine, but the term "chord symbol" is much more widely used, in the US at least, so that is what I propose the UI converge on in the US localization.
I have updated the design document with JoJo-Schmitz's suggestions. Most significantly, I have added a new "Semantics" section to the description of the parser that gets quite explicit about the meaning of the various chord symbol elements.
I'll probably continue to tweak it here and there as we go forward, and I won't announce every revision here, but I thought the additional of the Semantics section was significant.
Hi Marc
(I hope this topic is a suitable place.)
I came across this recently from a published sheet music book and wanted to ask: Is it possible to enter all of these chords?
In reply to Hi Marc (I hope this topic is by chen lung
This topic will do for now, but it's pretty out of date. I've already beyond what I proposed here to a system in which you can type practically anything you want and it will be rendered "as typed", but with nicer formatting. Here is a more relevant thread for future reference:
http://musescore.org/en/node/21202
But to answer your question: the parser can handle any of the symbols on the list from the perspective that you can type them, see something reasonable rendered, and they will transpose and *something* will export to MusicXML. Whether the MusicXML export will be what they say it should be is another matter. Several of those chords are just wrong, or at best slightly nonsensical. Eg, nothing about Csus42 says to omit the fifth, and this is not a sufficiently common symbol (to the point where I doubt I've ever seen it in decades as a professional musician) to warrant including special case rendering to get that vertical arrangement of the numbers in the rendering - unlike, say, C69, which is extremely common and *will* render vertically if you select the "jazz": rendering style. Similarly, no one ever uses "dim" to mean anything but a diminished chord - it is never used as they propose, to lower the fifth on a major chord. Likewise for "aug". So the chord symbols they list that use that use those abbreviations incorrectly won't export the way they say, nor should they.
The rest are all very straightforward and are handled exactly as shown, which is as any musician would expect.
In reply to This topic will do for now, by Marc Sabatella
Yes, the vertical one is what I was thinking about.
I first saw it in another book being used, before seeing it in the chord examples.
In reply to Yes, the vertical one is what by chen lung
Right, as I said, 69 is common enough, so the new default WYTIWYG mode will display that one as shown in this excerpt. At least, it will if you select the "Jazz" style in the new GUI that will hopefully be in place soon. The "Standard" style uses plainer rendering, in keeping with how chords like with stdchords.xml currently. But "69” in the Jazz style is the only place where I added explicit special case rules to get vertical rendering. If you wanted to get it for sus42 or any other chord, you'd still have to make that happen through explicit customization.
The customization process will actually become simpler as well. But this all in flux right now - some of the changes are already in the nightly builds, others are not. I'd rather wait until this settles down before writing up any detailed instructions on how to go about customizing the rendering of chords in 2.0. With WYTIWYG in place, the need for that sort of customization should be greatly diminished over 2.0, though. Basically, getting vertical rendering for chords other than 69 chords would be the only reason I would imagine anyone would be tempted to bother. At some point I might try to figure out a way to get this to happen automatically, but it's a lot trickier.