Add Support for Different Chords
Hi. I just got to trying out the new 1.1 lead sheet features and its really great. However, there is some added functionality that would be nice to see.
To my knowledge, it is currently impossible to create chords that are not in the xml file, such as Cma7b9 (C major7 flat9) for instance. It is also impossible to use parentheses in the process (Cma7(b9), for instance). While these are somewhat rare to see, it is still possible that they might be used in a lead sheet.
By its very nature, it would be impossible to catalog all of the different chords people would want to use in the xml file (it's very nature being that people can make up whatever chord they want). It is also unreasonable to ask people to add chords to the file if they need them, seeing as how many musicians lack xml knowledge.
I think the ideal situation would be if the different symbols (for instance, typing ma creates the MA symbol in subscript capitals, or the flat sign created by typing a lowercase b) appeared while still in edit mode, essentially immediately. So if one were to type "Bb", then the lowercase b would turn into the flat sign while the person is still in edit mode.
Here's why this would work:
In this situation, let's say I wanted Cma7(b9).
I would achieve this in the following way:
1) Type C
2) Type ma. Immediately this would turn into the subscript capital MA, without leaving edit mode.
3) Type 7.
4) Type the beginning parenthesis: (
5) Type b. This would immediately turn into a flat sign.
6) Type 9
7) Type the closing parenthesis: )
The result would be several characters and symbols strung together: uppercase C, the MA subscript capital symbol, the number 7, the beginning parenthesis (, the flat symbol, the number 9, and the closing parenthesis ).
This results in this chord: Cma7(b9).
This would give people more control over how they wanted to write their chords. It would also require that the "mi7b5" symbol be turned from one long symbol into a string of shorter symbols, like this: the MI subscript capital symbol, followed by the number 7, then the flat symbol, then the number 5. This would also require a separate way of making the half diminished symbol Ø. Perhaps typing in something like o/ would create Ø.
Thanks.
--Isaac
Comments
I'm totally with you. I would much rather see chords recognized via a parser that understands the common variations and the rules for combining tokens, rather than the current method of looking for exact matches against the XML file. Seeing the lead sheets posted to musescore.com and the forums demonstrates the problem with the current approach very well: people just aren't getting that they have to enter chords in a specific way. I've provided a choice of methods, but a) people aren't using them, and b) they still don't cover all ways people like to enter chords. So we end up seeing lead sheets in which a good percentage of the chords entered are actually invalid. So they look ugly and don't work right (with respect to transposition and MusicXML), but people aren't noticing.
I've proposed (via the developers mailing list) ideas for how a smarter parser could work - one that allowed any reasonable string to be recognized - but I don't have enough familiarity with the existing code to jump in and try implementing it myself. There's no denying it would be a pretty big change, and there was understandable resistance to the idea when I proposed it. I suspect MuseScore may be pretty hardwired internally to represent chords to with a single chord ID. I think it would be "relatively" easy to implement the parser, but changing the basic internal representation of the chord scares me more. Among other things, it means a file format change, it seems. There is also the issue of getting it to properly support MusicXML. But I still think it's doable and worth doing. I know when I initially proposed my idea, Werner was still in the process of working on a chord style editor, but I don't know that this was really going far enough. On the other hand, as far as I can tell, the two ideas are complementary. The parser is about recognizing chords; the chord style is about how they are displayed.
I don't know that I'm ready to do any real coding directly with the source, but what if I prototyped a standalone parser, say, using javascript, that was able to read a string, build an internal data structure representing the chord along the lines of what the existing harmony editor uses, and output valid MusicXML? Would that be something that someone else could then use as a model in implementing "for real"?
Good question (though it is one for which I have no answer).
Another thing that might be work could be to have a bunch of buttons, like on the F2 keyboard for all the different symbols. It's kind of cumbersome, but it would do the job, and perhaps it would be easier to implement in the interim, until something better can be figured out.
Autocomplete is also another option. You enter C and a list is displayed close to it with all the extension available if you type" "m" the list becomes shorter etc... Plus something to let you know that the chordnames is not recongnized.
I like auto-complete.
Correct me if I'm wrong, but it sounds like, with auto complete, the system would actually need to have a list of chords (as it does now with the XML file). This is self-defeating. The idea here is for people to be able to make up weird chords that probably wouldn't be recognized by the system. For instance: Cma7/B(b9#11) (C major 7 in 3rd inversion with a flat 9 and a sharp 11). This may seem strange, and it is, but we have to allow people to write whatever chord they want. It sounds like auto-complete would not do this because it would "let you know that the chord names is not recognized" (lasconic).
I also wonder how often autocomplete would actually be helpful. After I type "C7", there are still around a hundred ways that could potentially be completed. And if you want to enter a minus sign for minor, autocomplete won't help, as you'll already have entered the territory of unrecognized chords. The only thing it seems it mit help with is in showing you the two. Ain options are "ma" and "mi" if you start by typing "Cm". But it still doesn't address the basic problem: what if you don't want to use those abbreviations? That's the real problem that needs solving here. Once that's solved, then sure, autocomplete might provide some small value on top of that, but the more important thing is to actually allow more ways of entering chords, not just to better expose the li ited ways that are currently available.
I would just like to add that I would also be completely in favor of something like isaac is suggesting. I do a lot of samba, which has its own vocabulary of favorite chords, but I'm finding it impossible to produce chord symbols that would even be intelligible to someone trying to read the chart. I know nothing about programming, and have spent many hours dealing with the file trying to figure out how to get these chords, and while I've had some success at editing their appearance, when a chord doesn't exist, I'm kind of screwed at this point, unless I go learn how to write code, which shouldn't be expected of every user. This is definitely a deal breaker for me and musescore, which I love, but right now I can't produce legible charts. I'm including my comment here because I imagine there are others like me, who would like a simple way to enter chords. Doing exactly what isaac suggests seems extremely intuitive: if I want a 9 in the chordname, I type a nine wherever I want, and it appears as a 9 would in that chord style. This is certainly possible. I appreciate all of the work you guys do, thanks for the program! But seriously, this is a big issue. Thanks.
I still have hope that some day, I will find the time and opportunity to come up to speed enough to actually be able to go in and implement a chord parser along the lines of what I described in my response #1. This is not something I have given up on, as I too think this will be a crucial feature for MuseScore going forward.
Meanwhile, though, if there are specific chords you want to be able to enter that are currently not part of MuseScore's vocabulary at all, now would be an excellent time to tell me, as I am about to get started on adding the small handful of such requests that have come up since 1.1. While there is no official timeline for the 1.2 release, my sense is that I'll be wanting to get my changes in within the next week or two.
It could turn out to be the case, though, that the chords you want *can* already be entered, if you just spell them the way your currently loaded chord name style expects. And if you want to be able to enter them differently, it might be the case that one of the other provided chord description style files will already fit the bill, or that a small tweak to one of the existing files would do the trick.
So I'd suggest starting a new thread in the Support forum and list any specific chords you would like, and I can either help you see how to enter them now, or consider them for addition to the list of known chords. I can also help you see how to customize the chord description style files to get what you want yourself.
I finally got around to doing this :-)
Automatically closed -- issue fixed for 2 weeks with no activity.