Handling of unrecognized chords
Aside from slash notation , my other pet issue that I am hoping top see improved sooner rather than later is the chord name handling. A while back on the developer's list, I posted a somewhat grandiose scheme for replacing the current system that compares each typed chordname against an exhaustive list of possible matches with a system that parses the chordname, "understands" it, and then somehow records both the name as typed as well as the "understood" chord. This didn't generate a lot of enthusiasm, and indeed, it would be kind of a big change.
But this is kind of a big deal. A lot of users are currently generating scores with bogus chords (not recognized, hence not transposed, not export to MusicXML, and basically not displayed correctly) because they haven't researched the "right" way to enter chords and the role of the chord descriptor files. Recently I have started to wonder if we could do well with something like what Finale has (or had, anyhow - I haven't tried lately): a dialog box that pops up when you type an unrecognized chord and gives you options for dealing with it. The options might include letting you switch to a different chord descriptor file, popping you into the Harmony Properties dialog to build the chord that way, bringing up a window to allow you to add the chord to the list of recognized chords, etc. This would allow the file format to remain unchanged; it would just improve the user experience.
I could still also see writing a plugin or utility to generate a new chord descriptor file based on the user's expressed preferences for how he likes to abbreviate major, minor, etc, and all. I'm unclear on how exactly MuseScore 2.0 is going to handle custom chord descriptor files, how this relates to the "chord style" that can be saved, etc.
And while I didn't mention this in the thread on slash notation, yes, there is the possibility that I might be able to get a build system going and come up to speed on the code and look into implementing this myself. But I also get the feeling that maybe there is a push to wrap up new features, and I doubt I'd get to the point of being able to implement anything like this myself very quickly.
Comments
Another bump with some new points for discussion: I've been thinking more about this, and it is starting to take shape in my mind. Influenced by Finale, but hopefully better/easier.
An MSCZ file contains a link to the chord descriptor file, but my understanding is that there is also supposed to be some sort of facility for including at least a subset of the *contents* of that file. I'm not sure exactly what triggers this or if it is implemented yet; I'm still not conversant enough with the source to tell for myself. No matter; I think what I have in mind will fit in just fine in any case.
My proposal consists of several parts that should work together to solve most chord definition / recognition problems, without requiring any file format or significant architectural changes.
The first step is to provide a wizard that allows you to generate your own chord descriptor file from a few sets of radio buttons. One set where you select how you like to abbreviate "major", one set for "minor", one for "diminished", for "augmented", and for the various other easily parameterized aspects of chord description (whether to parenthesize alterations, etc). When you hit the "Finish" button, the wizard would automatically generate an appropriate XML file, prompt you for a location to save it to, and set the current score to use it. I should be able to leverage the work I did parameterizing the "cchords" descriptor files for 1.1 to make such a utility fairly easy to create.
Even with such a wizard in place and a potentially customize chord description already in effect, unrecognized chords are occasionally a problem due to fact that not every possible chord is listed. So I would also propose a facility to add a new chord id on the fly and describe how you want it displayed. To describe how you want it displayed, I would leverage the existing 2.0 chord style editor - I'd just pop up that dialog already positioned on the newly added chord id.
Ideally, I would see MuseScore also implementing a chord parser that kicked in any time a user typed a chord not immediately recognized using the current chord descriptions. The chord parser would know the most common variations on chord symbol nomenclature and would try to figure out which chord id the user was getting at. MuseScore could then could pop up a dialog giving you the option to have the "correct" spelling substituted automatically (if the parser succeeded in figuring this out), of running the wizard to generate new chord descriptions, of adding a new chord id that you could then describe yourself using the chord style editor, of letting you correct the spelling yourself, or of simply accepting the unrecognized chord.
Again, I think this would pretty much solve the existing issues that users have with chord names, without requiring file format or architectural changes - indeed, hardly any code changes at all aside from addition of these the new facilities that would only be triggered when the user invokes them or types an unrecognized chord.
I can see doing some of this work, especially the standalone portions - the guts of the wizard to generate chord descriptions and of the chord parser. I could probably use help with the UI and with integrating with the rest of MuseScore, though. And realistically, I couldn't really get started on any of this until the middle of November. So I am not sure if this is something that makes sense to try to squeeze into 2.0 or not.
I suppose maybe this is a more appropriate discussion for the developer mailing list? I have to say I like the forum interface better, though.
In reply to A more concrete proposal by Marc Sabatella
Arguably, the dev mailing list could be a more focused place, but the forum interface is much more slick indeed!
I know near to nothing about this way of notating chords (for me, anything after J.C. Bach is avant-garde...), but you are quite at ease with it. On the other hand, I have some familiarity with MuseScore code and some experience in adding stuff to it. This may suggest something, doesn't it?
Time frame might be an issue, though. And time frames, schedules and dealines are for the core developers to set. So, if lasconic/Werner/Thomas can set a deadline (at least indicative) for inclusion (taking into account debugging / testing), then we could plan with more confidence.
From what you outline above, there seems to be some work involved, but nothing inordinately tricky. So, it might not take too much time (once we know how much is too much).
M.
In reply to Arguably, the dev mailing by Miwarre
Thanks for the offer to help, and collaborating on this would be fantastic, I think! Yes, let's see what the core guys think, both regarding the idea in general and the time frame. To my thinking, though, this is the one completely new thing (as opposed to just finishing up the things already started) most worth adding for 2.0. Obviously, though, it's only relevant for jazz/pop/rock/etc, and therefore is probably not worth delaying a release for, and since no architectural changes would be involved, it could just as easily wait for 2.1 if necessary.
BTW, not to talk anyone out of making room for this in MuseScore proper, but there is actually no reason the chord description wizard and the facility to add new chord id's couldn't be done as a plugin or a completely standalone utility - except, of course, for the part about parsing unrecognized chords and sending them to the new utility automatically, or setting a score to use the newly generated chord description style file. So the integration wouldn't be very good, but the basic functionality would. And a standalone utility written in C++ could presumably be written in such a way that it would be easy to incorporate into MuseScore later. So that's my plan B.
In reply to Thanks for the offer to help, by Marc Sabatella
The way I would see this working is as a separate application that is run by MuseScore when needed, thus saving on processor and memory resources when it is not required.
One of the current confusions in 1.2 is the way you write a chord is totally dependent on the chord descriptor file you currently have access.
Consequently if you have cchordsmuse.xml active you have to type a "mi" suffix for a minor chord. If you just use "m" the parser won't recognise it.
If there can be a way to change this, it would make the whole chord input interface far more user-friendly.
In reply to The way I would see this by ChurchOrganist
My original proposal from a year or so ago was desogned to let you type practically whateve ryou want, have it be parsed, and if understood, it would be accepted as is. But implementing a scheme like that would have required some pretty significant architectural changes, and no one seemed ready to accept that. And actually, I rather *like* the idea of MuseScore enforcing a certain consistency - I just want it to be easier to control what Specific symbols MuseScore recognizes. Hence, this new proposal that is really just a way of easily customizing your chord description file.
In reply to The way I would see this by ChurchOrganist
External vs included
Processor time is not an issue here: while such a function is not required (and then not run), it would not take any processor time. True, if it is linked in the main programme, it would sit in memory doing nothing until needed. This is also true for a number of other MuseScore pieces; for instance, the New Score Wizard simply wastes memory until you actually create a new score and need it.
There are added complications for the external app approach either: path consistency (MuseScore would have to find the external app) across OSes, lag while loading it, and for sure other not coming to my mind on the spot.
It mostly depends upon its size: if including it in the main code doubles or more the executable image -- which is VERY unlikely --, making an external app MIGHT be an option. Keep in mind that the debug version under Windows is ca. 8 times larger (228 MB instead of 28MB) than the realease version and it still works on any score.
So, unless there are workflow reasons for making it an external app, I would not bother...
Range of application
It is true that it would be relevant only for some genres; however, they seem quite widely represented in the MuseScore user base, so it MIGHT be a significant addition. But again, this is for the code developers to tell.
Thanks,
M.
In reply to External vs by Miwarre
The only reason I brought up the possibility of making it external would be schedule - if it's too late to include in 2.0. Or, if there are thought that something like my more grandiose scheme might be implemented post-2.0 (and thanks, David, for the link to that).
In reply to A more concrete proposal by Marc Sabatella
I'm at a point where I'm ready to give this more serious thought - putting together a concrete design proposal. My assumption is the more radical plan I outlined previously is still out of the question, but unless I hear otherwise, I am going to start on what I proposed a couple of posts above. And by "start", I mean, getting more specific as to algorithms and UI, in hopes that Miwarre or someone would still be able to help with coding, and hope it's not too late for 2.0. And if it is, then I'll turn the XML file generator into a standalone utility.
In reply to I'm at a point where I'm by Marc Sabatella
If it doesn't make it for 2.0, it will make it for the version after this, don't hold yourself.
In reply to If it doesn't make it for by [DELETED] 5
OK. I will be giving this some serious thought over the next few days, then, and I will write something concrete up.
In reply to I'm at a point where I'm by Marc Sabatella
I'm still interested in helping with coding; I'll leave to you working on the specs and sketching the algorithms, as you are far more familiar with the topic: better to keep it as high level as possible, without bothering with implementation details, they will follow (more or less!) easily, once the specs are defined.
M.
Here's a link to the original discussion on the mailing list.
http://dev-list.musescore.org/Proposal-for-Chord-Symbols-td6086981.html
I'm still a fan of something less obtrusive than the popup dialog that Finale has. (When I create one-off pieces using the default score setup instead of a customized template, I find it annoying to teach Finale what each unrecognized chord name means).
In reply to Original thread by David Bolton
On re-reading my older proposal, it's still pretty solid, I think, although I'd probably change a few details. Depending on what we hear about schedule, I am certainly not averse to trying to flesh this out more and investigate the feasibility. But no doubt, it's a bigger change.
Here's a couple of other hurdles:
What about those chords where 3 of the notes move, but the melody/submelody hits a note out of the chord? Will it notify you every time you do this? Even worse, if I have a CMaj chord, and my melody goes g-a-g, will the chord with the "a" all of sudden become a Amin7 chord? (Basically, when is a note part of a chord, and when is it a moving note)
Secondly, what about chords that don't include all of the notes? C-E-Bb is definitely a chord, even though the G isn't there.
Thirdly, are you going to parse broken chords?
Fourthly, I agree with ChurchOrganist. I think the best place for this would be an app that runs on demand, not on run-time.
Finally, I think it would be awesome if it also included basic theory, and would be able to guess whether or not things "sounded" good, and furthermore, if it could generate chords for you in the future.
In reply to Here's a couple of other by thenameipicked
I think you are misunderstanding what we are talking about here. I am not proposing anything at all happen when entering *notes*. I am only talking about what happens when you type chordnames. Ere will be no parsing of notes, no looking at notes in any way whatsoever. Again, I am only talking about what happens if you click ctrl-K to enter a chordname then type "Cmaj7". It won't matter what notes, if any, you have entered.
So what I am talking about *would* run only on demand - it would kick in only when you type a chordname, and when the name of that chord is unrecognized. No changes whatsoever to anything having to do with notes - only chordnames.