chord weirdness
Hi everybody, can anybody figure out what's going on here? Thanks for any help
When I do a leadsheet and then save it as an mscz file, the chord
> names are saved OK. When I then try to save the lead sheet as an mxl
> file a few of the chords appear in italic, moved upwards approximately
> into the lyric line of the line above, and the flat signs, for
> instance, appear as empty boxes. Correcting them and re-saving it
> doesn't change anything - they are still where they were in the wrong
> place. If I could attach the files you could see for yourself.
> There seems to be a lot of bugs that still need sorting out in Musescore.
> Also, I still can't upload the mxl file to publish it (after deleting
> the original chords and putting simpler basic chords in, which is a
> bit pointless, but that seems the only way to get an mxl that is not
> as it should be, but at least not WRONG). See earlier message yesterday.
> Alan Rogers
See attachments
| Attachment | Size |
|---|---|
| WHO2a.mxl | 3.21 KB |
| WHO2a.mscz | 3.48 KB |
Comments
Hi Alan -
Thanks for the attachments.
Which version of MuseScore? Which OS?
Fifist
In reply to Details? by Fifist
Hi Fifist,
It's MS1.2 and win7.
IT seems that the problem is chord recognition. Like E7b9 is ok but E9b isn't. And it seems it will not recognise Emaj7b9. This might be a strange question, but why can't MS recognise all of the various standard forms of chord signatures? It's not as if someone is going to write B***s as a chord name - but even if that were the case, I can't see the necessity for imposed limits on chord names. If it is necessary, why is it necessary?
Notator has been around for 30+ years, and sized c. 5 Mb and still 30 years later in many respects it is easier to use and out-performs programs 50 and more time the size. Thank God for my (hope hope) indestructible Atari!
Thanks for the help,
Alan Rogers
In reply to chord weirdness by Alan Rogers
The problem is that E9b just looks like like a syntax error - like you meant to type E9b5 but forgot the 5. Is that what you meant? Or did you mean an E triad with an added b9? Putting a flat sign after an extension might appear to be a clever way way around tha,t but it just isn't really standard practice, so there is no way MuseScore could possibly have figured out this is what you meant - if in fact it is what you meant.
The question of why MuseScore needs to understand a chord symbol isn't strange. It is a valid question, but it has an equally valid answer. MuseScore needs to know what the chord symbol *means* for several reasons. Most relevantly here, it needs to know the meaning in order to export to MusicXML, because that's how MusicXML works. MusicXML doesn't just record the name you typed - it records all information necessary to allow the chord to be constructed note by note. MuseScore also needs to understand chords at some very basic level in order to transpose them properly - it needs to know which symbols within the chords are note names and which are not ("b" can be either, deopending on context, as can several other letters - consider symbols like alt, add, etc).
Most importantly, though, MuseScore currently also needs to recognize chords in order display them. MuseScore uses a chord description style file (as explained in the Handbook page I referenced previously) to determine how to display chords - what font and size to use for the various pieces of the chord, how much to superscript various elements, what character subsitutions to make (flat sign for "b"), whether to add paranetheses around alterations, etc. All this is highly customizable, but customization only works if MuseScore understand what you have typed. It can't superscript an alteration if it doesn't recognize that this is what you've typed, for instance.
So that is whj it is necessary to impose limits - MuseScore needs to recognize the chord in order to understand enough about it to properly export it to MusicXML, transpose it, and display it.
That said, sure, it could definitely be more forgiving. Right now chord recognition is a very simplistic algorithm - there is a list of recognized chords in each chord description file, and MuseScore just does a simple string match against each item in the list until it finds a match. Then the rest of the information for that chord in the chord description file provides the necessary information on MusicXML export, display, etc. So that is why there are several different chord description files provided - so you can choose which best matches your preferences. And you can curstomize any of these files to better suit your preferences - including adding an entry for "E9b" if you should care to create the necessary rules to help MuseScore understand what that means - how to display it and how to export it to MusicXML.
I'm not one of the developers of MuseScore, but as you can see, I've done a lot of work on the subject of chord symbols "behind the scenes" (including having created seversal of the chord description files shjipped with MuseScore, to allow one to mimic several popular styles, such as that used in the Real Book and New Real Book series). I'm working hard to get some changes I've proposed into MuseScore 2.0 that would allow you tyoe tyope anything "within reason" and have MuseScore be able to parse it and understand it, and then match it against one of the chords in the chord description file even if you didn't type it the same way. So you could type either C-7 or Cmi7 or Cm7 and it would be understood as a C minor seventh. But it would still display according to the rules in the chord description style you have selected, because actually changing the rendering system of MuseScore to not use the rules in the chord description file is a much bigger change to the program, and will probably have to wait for a future release.
As for Notator, I'm impressed and amazed you've got still got your Atari working! I was a former user of Notator too, and I still consider it the gold standard for usability in a lot of ways. Also for integration of MIDI. But I do think you'll find that as you become more familiar with MuseScore, that is capable of many things Notator was not, and that many things are actually easier in MuseScore once you realize how they work. Even though there are still many aspects of Notator that no other program can touch.
something like: http://musescore.org/en/node/9691
See in the image (in blue) a suspected problem
The reason some of your chords are giving you problems is you entered chords that are unrecognized. If MuseScore doesn't recognize a chord, it can't export it to MusicXML, because MusicXML uses more than just the raw text of the chord symbol. See the Handbook entry on [[nodetitle:Chordname]] and select the chord name style that best matches how you prefer to enter chord symbols.
Some things to note -
- Do not use an explicit flat or sharp sign in a chord symbol, ever. MuseScore expects you to type "b" or "#" and it will convert to flat or sharp automatically if the chord syjmbol is recognized. If it is not recognized, then you need to figure out what MuseScore expects and type that instead - or, as mentioned, switch to a chord name style that speels chords the way you want.
- "aug" is not the abbreivation used for augmented chords in the chord name style your score uses. Instead, use "+". Or switch to a chord name style that does use "aug", but then you might not like the abbreviations it uses for major and minor.
- E9b is not going to be a recognized in any chord name style. It appears it might have been a typo, but I suppose maybe you were trying to indcate an E triad with an added b9, but no 7? There is no standard chord symbol to denote that, and nothing you type into MuseScore (or moist other notation programs) will allow such a thing unless you explicitly set it up to do so by customizing the list of chord symbols (which can do in MuseScore by editing the chord name style file). Based on the context here, I'm thinking just using a standard E7b9 would be the way to go.
Not sure what you mean about uploading the MXL file to publish it - publish it where? Do not that MusicXML is not perfect, and not really suitable for most types of publishing. It just can't retain enough information about your score to be nearly as WYWIWYG as you would want. There will always be difference - some subtle, some pretty major - between how your score looks in whatever notation program you developed it in and how it looks in the program that imports the MusicXML. Even just exporting MusicXML and importing into the same program produces pretty drastic differences in most cases. MuseScore is actually noticeably better than Finale in this regard.
In reply to The reason some of your by Marc Sabatella
Hi Marc,
It seems you're right and that the problem was/is chord recognition. Like E7b9 is ok but E9b isn't (How can you have a b9 without a 7? Or a 9 without a 7? If there were no 7 it would be a b2 or a 2, so putting in the 7 is irrelavant) . And you say it will not recognise Emaj7b9. This might be a strange question, but why can't MS recognise all of the various standard forms of chord signatures? It's not as if someone is going to write b******s as a chord name - but even if that were the case, I can't see the necessity for imposed limits on chord names. If it is necessary, why is it necessary?
I wanted to do an experimental upload to Wikifonia, as it only recognises mxl or xml files, but every time (and still now, after altering the chordname format) when it says 'How does your page look?', the page is blank.
Notator has been around for 30+ years, and sized c. 5 Mb and still 30 years later in many respects it is easier to use and out-performs programs 50 and more times the size. Thank God for my (hope hope) indestructible Atari!
Thanks for the help,
Alan Rogers
In reply to chord weirdness by Alan Rogers
[ looks like two different versions of your post appeared; I'll respond here to the points not duplicated in the first version ]
There is no standard symbol for a chord with a b9 but no 7. This isn't some arbitrary limitation of MuseScore - I'm saying, there *is no standard symbol*. Nothing a human musican would be guaranteed to recognize, either. So you are definitely discouraged from trying to use symbols that no musicians would have ever seen before. Keep in mind that chord symbols beyond triads are treated by musicians as rough guides - they virtually never are interpreted as exact recipes for what notes must and must not be played. So even though the particular voicing you have in mind might not include a 7th, chances are it is still perfectly appropriate, and even if you tried to trick a musician into playing a voicing with a b9 but no 7th by cleverly wordsmithing the chord symbol, he'd by likely to include the seventh anyhow, because functionally in that context, it makes total sense to include it and no sense to omit it. Musicians generally make their own voicing decisions based on a relatively sdmall set of common symbols. And that is why you might look at 1000 pages of fakebookand and never once encounter a symbol like Eaddb9.
That said, if I absolutely needed to create a chord symbol for a triad with an added b9 even though I knew it would be meaningless to most musicians, I would probably write Eaddb9 and cross my fingers. And I'd have to add an entry for this to my chord description style to get MuseScore to do anything with it. But again, using such a non-standard chord symbol is just asking for trouble when it comes time for a human musician to actually read the chart. You'll sight reading errors galore as musicians try to parse and understand a chord symbol they've never seen before, head scratching as they try to figure out how to voice it effectively since they've never played it before, what and fumbling asd they improvise over it trying to figure out what notes fit the chord well, since they've never improvised over it before. It's virtually never never worth it.
E with an added ninth that is *not* flatted,, on the other hand is much more common and pretty simple: Eadd9, Eadd2, or E2 would all be recognize instantly by most musicians. And one or more of these is likely to be recognized by whatever chord name style you select within MuseScore.
MusicXML does make sense for Wikifonia, but this definitely underscores the value of creating something easily understood and not making up your own chord symbols. Realize that due to the nature of MusicXML, your score will never look *identical* to how it looks in your notation software - MusicXML just doesn't contain that level of detail about appearance. So it pays to create scores that are somewhat "generic" in nature and not relying on the diosyncracies of the program you used to create them in order to display something non-standard, but instead.
In reply to [ looks like two different by Marc Sabatella
Hi Marc,
thanks very much for the great effort you put into helping me in my problem with chord symbols.
My stance is that (and I know here I'm "kicking against the pricks") chord symbols should be written in the simplest form possible consistent with not being able to be misinterpreted. For instance Ej7 instead of EM7 (which, unless it is in a good typeface or you haven't got your reading glasses on, can be easily mistaken for Em7): E° instead of Edim7; E+ instead of Eaug5; and so on.
Also, when one wants to designate an E6 it is not necessary to write E3-5-6, as one assumes the third and fifth, otherwise it could well be a different chord anyway. Similarly, why do I have to write E7-9b? If the seventh (even if it isn't voiced) wasn't in the chord the flattened ninth wouldn't mean anything. So if I write E9b, what else could it mean other than a flattened ninth?
This was my first serious delving into the depths of MuseScore – I've used it a bit previously when somebody has given me a lead sheet that was already in the MuseScore format – as the existing lead sheet on Wikifonia had chords on that nobody I know would ever use, so I presumptuously thought I would upload my version onto it. I've corrected all the chords into what would seem to be the proper format (when I open the mxl file in MuseScore it looks perfectly okay), but it still won't upload properly. I've e-mailed Wikifonia to tell them of the problem but as yet have not received any answer.
Once again, many thanks for your help,
Alan Rogers
In reply to chord weirdness by Alan Rogers
For the record, if I were designing chord symbols from scratch - I mean, if I could go back in time a hundred years or whatever - I'd be pushing for something very different from what has actually developed. But here, I'm trying to be pragmatic - how to beat deal with what musicians have come to actually use and expect, not what would be best if we started from scratch and taught musicians our new system.
MuseScore does, as I mentioned, allow you to customize how chords and entered and displayed. So if you want to use Ej7 (which is perfectly logical but something i've never seen in my life), you can edit one of the chord description files to do this. But that will work within MuseScore only. MusicXML does not work by encoding the *appearence* of the chord symbol but rather by encoding the *structure* of the chord. So the MusicXML file will just record that you meant a major seventh chord, and the program importing that MusicXML will display it however that program is configured to display major seventh chords.
Meaning, if your ultimate goal is to produce a MusicXML file, it isn't worth the effort to customize MuseScore's handling of chord symbols - none of your cuatmizations make it into the MusicXML file. Enter the chords however MuseScore expects, and know that it may well be displayed entirely differently by the program that then imports that MusicXMl file - that's just how MusicXML works.
BTW, I don't know why the chord symbol system as actually employed by musicians doesn't allow for an easy way of specifying a triad with a an altered ninth shouldone want to, but there really is no arguing with the fact that this is true. You essentially won't find this symbol, ever, and musicians seeing it will not understand what you mean. The standard is that alterations like b or # precede the number, they don't follow it. So E9b will just look like a typo, regardless of your intent. Musicians will look at it and think, "E nine flat *what*?" They will play an E9 chord and then they'll probably guess you meant b5. So you'll get E-G#-Bb-D-F#, which is a far cry from what you wanted. Sorry, logic may suggest this would be a way to get what you want, but reality is otherwise.
Anyhow, feel free to attach your MSCZ file to a post here and I or others can take a look to try to see if there is some reason - either something wrong with the score like an unrecognized chird symbol, or a bug in MuseScore - that is causing it to export to MusicXML incorrectly.
In reply to For the record, if I were by Marc Sabatella
Hi Marc,
once again, thanx for the time you've taken to comment on my thoughts, weird as they might seem.
Two points: firstly, it would appear that the problem with uploading to Wikifonia was due to a problem involving Internet explorer, because, on a whim, I downloaded and used Google chrome to try to upload the couple of songs that I'd been using as test pieces to get to grips a bit with MuseScore - and, lo and behold, up they went without a hitch. Still don't know why this is/was so, but it is/was.
Secondly, it 's probably a US/UK thing, but Ej7 is used quite frequently over here, and you must admit that it's not likely to be construed to mean anything other than E major 7th (in my experience, musicians are not unusually dim - some exceptions, of course - so I think using Ej7 would not cause hours of mental struggling and the collapse of the US music industry), and takes a lot less time to type and takes up a lot less space than EMaj7 (or Emaj7).
I also am not at all convinced that the present fairly good chord symbol system cannot, by mutual agreement, be polished up a bit. That would be like saying, 'If it was good enough for Jesus, it is good enough for me'. That sort of thinking is not what I accept at all, in any sphere of life. Surely one would only need to say once, 'When I put E9b, I mean E flattened ninth', and from then on everybody thus informed would know, and think, 'Oh, good, now I don't have to type E7-b9 any more'.
The two songs I uploaded to Wikifonia are 'Who', and 'Rockin chair', by the way. In my struggle, somehow 'Rockin chair' got uploaded twice - again, no idea why.
So there they are, sitting targets for abuse, ricicule, etc., and maybe the odd grudging, 'Well, at least they're better/more interesting than the crappy ones one usually gets in sheet music'. Or not, who knows?
Alan Rogers
In reply to chord weirdness by Alan Rogers
Good to know that "j" is common in some circles - I wasn't aware of that. And absolutely, there is a *ton* of room for improvement in the current chord symbol handling - as I believe I mentioned previously, this is something I am very actively pushing for and in fact it looks like there will be some significant progress for 2.0.
Depending on these current discussions on improvements to the chord symbol handling pan out, this may become moot, but could you summarize the style of abbreviations you find most common in your area? As, how one would commonly see major seventh, minor seventh, half-diminished / minor seventh flat five,. diminished, how alterations are expressed, etc? I'd like to incorporate all sufficiently common abbreviations in the parser we are putting togehter, and if we don't settle on a scheme where MuseScore actually displays what you typed, but instead keep the current scheme where it uses a fixed chord description file to display the chords, we could at least consider putting toigether a customize "cchords_uk" chord description file that would allow chords to be displayed that way.
In reply to Good to know that "j" is by Marc Sabatella
Ot, or not Ot: that is the question...
is this useful?
http://www.suonolachitarra.it/blog/notazione-letterale-o-anglosassone.h…
sandroden has found a brilliant solution for chord names here (Italian forum) :
http://musescore.org/it/node/20086
see attachments
"cchords_rb_it.xml"
"cchords_muse_it.xml"
In reply to @ Marc by Shoichi
Not OT!
Direct support for this style of chord naming (based on what English-speaking people might refer to as "solfege" note names) is part of my proposal as well, although it hasn't been the primary focus. I already added the glyphs for these syllables to MuseJazz for 1.2, which is what mades the modifications to the "cchords" files possible. For 2.0, assuming we get the parser in, the parser would have to understand Do for C, etc. Although I suppose you'd have to explicitly enable this or else there would be room for confusion - Do7 might be taken for "Do 7" (dominant seventh chord built on the note C aka Do)or "D o7" (diminished chord built on the note D aka Re).
In reply to Not OT! Direct support for by Marc Sabatella
Hi Marc,
Thanks for the quick reply.
Unfortunately, my email server seems to be going through a bumpy patch at the moment, so I can not be sure to receive emails promptly, but I can at least keep up to date by following this forum on the internet OK.
I attach my suggestions that have been looked over by a few fellow pro jazz musicians, and no-one as yet can pick any great holes in it. If I've missed out any chord form of importance, I'd like to know so that I can suggest what symbol I would propose to use to denote it.
Alan Rogers
In reply to chord weirdness by Alan Rogers
On first glance, your writeup appears both clear and thorough, but I'm still trying to understand - is everything on that actually in common use? Is there published sheet from major publushers that use these conventions, or if it oerhaos more of an "underground. Thing? And if the latter, how widespread do you figure it is?
I ask because I have *never* heard of anyone writing an alteration after the degree to be altered, and I'm not sure it's really possible a a single parser to deal with both that and the more traditional method where the alteration comes before the degree. If this practice really is widespread and in use by major publishers, then I will endeavor to find a way to support it. But if it's just a small handful of people using this convention among themselves, I'm frankly not convinced it would be worth the effort to comllicate the parser just to support that style of notation.
Hi Marc,
As I say in the (again) attached text, the 2 overriding factors in my proposition for a chord symbol system are 1: compactnessand 2: logicality and (assuming that musicians aren't complete morons, which in my experience they aren't - though I must admit a very small few teeter on the edge), with a minimum of thought, cannot be construed to mean anything else. Your example of a symbol being assumed to be a misprint doesn't really hold water, as a misprint is possible anywhere, and I doubt that a reader would be inspecting every chord symbol for possible misprints while trying to play the score. (If they did, they'd be a bit like those people who avoid stepping on the lines between the pavement slabs as they walk along the sidewalk.)
I have seen all the symbols I propose used before. I'm/we're trying to construct a system having the 2 properties mentioned above, and it will obviously not have been used in its entirety before, otherwise we would not be inventing, we'd be plagiarising.
The whole point of the exercise is to come up with a NEW system that is as outlined in points 1 and 2. Sometimes it is necessary to think out of the box a little, and as far as I can see from our discussion, the more or less single major point you think is a stumbling block is whether the flat sign can be put after the 9th or whatever to indicate it's flattened. If, in the decription of the chord symbol list it is so defined, I can't see all musicians falling on the floor frothing at the mouth at the mere thought of it. At one time in their lives, they had to have every symbol in a system defined for them, and (to malign the memory of Mr Ludd of Luddite fame - he actually wasn't against change as such) musicians as a whole I have found not to be Luddites, and generally open to change, especially if it's beneficial in some way - as I propose it would be/is here.
To hammer home the point a bit, US and European musicians seem to be able to come to grips with their present mish-mash of systems, so the introduction of a compacter and more logical system may well be welcomed.
As I said before, 'If it's good enough for Jesus, it's good enough for me' way of thinking is not conducive to anything beneficial (in the world of music or any where else).
Alan Rogers
In reply to chord weirdness by Alan Rogers
OK, I now understand you to be proposing something new, not describing what is actually common existing practice in your country, which is what I thought you were saying previously.
Since it will complicate the development of the parser to support this directly, I can't see trying to do that for 2.0 - we'll be lucky to get the parser in at all. But if you do have success getting other musicians - and publishers - to adopt your proposal, then indeed, MuseScore should support it. MuseScore is definitely in the business of supporting common existing practice where at all possible.
Meanwhile, MuseScore does provide a facility to allow you to customize how it recognizes and displays chords - the chord description XML files. Getting any of the "cchords" files it to support "j" is easy enough; just follow the instructions at the top of the file. But since your system is so radically different from the standard in terms of placement of the alterations, you'll unfortunately have to modify the "name" field for each individual chord that uses alterations.
But FWIW, I do maintain that a musicians seeing E9b is *extremely* likely to see that as a typo. It's not that we go around looking for typos, it's that we recognize chords based on our experience and familiarity with convention, and that simlle does fit. So we quite honestly would have no idea what to make of it. Some might guess you don't understand how chord symbols are written and figure out that you were trying to say b9, but most woild probably do as I described before - assume you simply left off a 5 at the end. We can't read your mind to know that you are proposing a new system of chord symbols. We can only try to interpret what we see based on our own experience. If you are able to explain to musicians first that you are using your own unique nomenclature and teach it to them before the gig, then of course, they should be able to understand.
In reply to OK, I now understand you to by Marc Sabatella
I would probably interpret E9♭ as a chord of the minor ninth with E as it's root, assuming the author had missed out the 7
Indeed it would seem most strange to have chord modifiers placed before the key modifier as it immediately raises (or lowers) the note by a semitone, and makes very little logical sense. After all we talk about E flat or B flat chords, and it seems a nonsense to place the sharp or flat after a numeric chord modifier, and bound to cause confusion, as the existing terminology is well entrenched in Western music theory.
In reply to I would probably interpret by ChurchOrganist
It's kind of like the same way different languages place articles and tense in different orders.
In reply to It's kind of like the same by xavierjazz
Yes, anddon't get me wrong - I have no argument with the "logic" of what is being suggested. I'm just not sure about spending the effort complicating the parser to handle both forms without a bit more existing practice gets behind this alternative method. On the other hand, MuseScore is open source, so no reason a motivated prorammer couldn't add this himself. I can't say for sure when we'll be looking at trying to add the parser - again, I'm not one of the programmers, but I have been actively pushing this by doing some detailed design work and corresponding with some of the programmers. Just speculating. but the actual work could potentially start happening with the next few weeks, and be done within a few weeks after that, depending on how far we take it.
In reply to Yes, anddon't get me wrong - by Marc Sabatella
Proposal for a standard chord symbol system
The reason this has taken a while to appear is that I’ve given the proposal(s) to several of my friends and fellow musicians for their comments/etc. However, all responsibility for any shortcomings/oversights is, of course, mine.
I thought at this point that it would be better to outline where I'm coming from in this debate about my proposals.
For many years I worked as a scientific and technical editor before becoming a full-time professional musician. Part of my work at this time was to ensure consistency in (and between) the books I was involved in publishing: fortunately, in the UK a short while before this, the SI (Système International) units convention had been established for use in all scientific and technical areas, which made life a lot easier.
Later, as a full-time professional musician faced with lead sheets having, for example, at least eight different symbols for a major seventh, I came to wonder how this situation could be tolerated. It wasn't because the different symbols are ideologically different and so could not be accepted — as was for a long time the case with the SI system in the US, where it was thought by some people to be a Communist takeover plot (I'm not joking, some idiots really thought that!). The real reason, of course, was economic: the cost of converting equipment and machinery to the new system.
So, all I am proposing is that a system of chord symbols is put forward for general acceptance that is concise, logical and easy to read. I hasten to add that in this system all the chord symbols have been used before in the various systems and therefore with, I think, a single exception (e.g. E9b), none of the symbols are my own invention (though it may well be the case that this notation has also been previously thought of and used by somebody, somewhere). The other new one is the suggestion by Bob Barton - see the details in the attached pdf file.
I set out my proposed system (and the reason for the choice of symbols, where necessary) in the attached file, as the space here is limited.
Finally, as an aside, an example of where mixed symbols/units can have a rather large and disastrous effect:
In 1999 NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency’s team used the more conventional metric system for a key spacecraft operation.
The units mismatch prevented navigation information from transferring between the Mars Climate Orbiter spacecraft team in at Lockheed Martin in Denver and the flight team at NASA’s Jet Propulsion Laboratory in Pasadena, California.
Lockheed Martin helped build, develop and operate the spacecraft for NASA. Its engineers provided navigation commands for Climate Orbiters thrusters in English units although NASA has been using the metric system predominantly since at least 1990.
In reply to chord weirdness by Alan Rogers
Hello All,
Seems like my chord symbol system proposal has stirred up quite froth of interest. Ha Ha Ha Ha Ha... .
I guess everyone's hoping I'll go away and quietly gibber to myself in a corner and stop prodding them to read and think about what is really an extremely slight adaptation (it's not big enough to be called a change) to make the present shambles of chord symbols into a more concise, logical and unambiguous system.
Of course that's after you've overcome the huge intellectual leap of saying '9th flat', the same as you say 'E flat' or 'B flat'.
Good job our forefathers were a bit more adventurous, otherwise the West would still be Unwon and good old Noldi wouldn't have had a place to go and prove (if anyone thought it still needed proving) that you don't have to be able to add 2 plus 2 to get voted into political office.
In reply to chord weirdness by Alan Rogers
Well, to be honest, as I've said before, whether or not your proposal seems logical or not is beside the point as far as I am concerned. Until I see evidence that real musicians out there are actually using this system, I can't really see any reason why MuseScore should go out of its way to support it. All sorts of non-standard notations have been proposed - not just for chords, but for representing pitch, rhythm, etc. MuseScore can't possibly add support for them all. So it makes sense to limit ready-made support to systems actually in use.
And actually, MuseScore *does* support pretty much any variation in chord symbols you care to think of - you just have to customize the chord description files yourself. Which is to say, if you wish MuseScore to produce chord symbols with abbreviations the way you describe, all you have to do is customize one of the XML files yourself. Then you would be free to use it all you want, share it with any friends who are also interested in this system, etc.
And then, if someday your systems starts being in common use, then it would indeed make sense to provide your customized files as part of the MuseScore distribution, along with the files that are already provided that mimic other common styles actually in use.
In reply to Well, to be honest, as I've by Marc Sabatella
don't you see the hen and egg problem?
In reply to don't you see the hen and egg by Jojo-Schmitz
Hi Jojo,
Who? Me or Marc? I guess you mean me, as the arrows in this discussion seem to be relatively mono-directional, but logically it could be either of us.
As in, "What, sail west across the ocean? No-one else has done that, so I'm not going to either - and I'm not going to tell anybody you suggested it". (Anon)
Or, "What, introduce a bit of common sense and spell 'colour' as 'color'? Do you think I'm stupid enough to do that? I might get away with it in the US, but in England? Forget it". (Noah Webster).
Or, "You must be an idiot, everybody is happy with furlongs, water boiling at 212° and freezing at 32°, fathoms, 'loud enough to be heard 200 yards away', bushels, pecks and so on - do you think anyone's going to promote and then adopt a logical and concise system of measurement for the entire world? Think again, mate. You might have a bit of luck with Europe, Asia, Africa, Australia and the Fiji Islands; but America? Forget it!".
LOL ('Lie' or 'lay'? Oh God! - decisions, decisions, decisions... .)
In reply to chord weirdness by Alan Rogers
no, I replied to Marc. Without the ability to use a new notation it can't get used and without getting used it won't get added to notation softwar. Catch 22
In reply to no, I replied to Marc. by Jojo-Schmitz
Yes, I agree, a new system won't catch n without software support in this age. Thirty years ago there was a better window of opportunity. I often wish I had been earlier so I could fix some bad design decisions - like whomever decided to base our notation of rhythm entirely n note length that than beat position. The single worst mistake in all of notation, in my opinion. But I've resigned myself to it, becusse it's too late to fix. There are dozens of more logical proposals to replace it that would make sense if we could change history, but at this point, effort spent getting MuseScore to support every proposed new form of music notation woild be counterproductive - there would be no time left to support the conventional notation that millions actually use.
Anyhow, as I have observed, MuseScore *does* support the proposed chord symbol notation, or just about any pther notation anyone would like to invent. You just have to customize the chord description XML file yourself. Seems fair enough to me.