An odd chord expansion? / "Materialize chord"
Musescore community / General discussion Forum
Recently I encountered an uncommon, bizarre chord notation: A5-7.
This pattern is accepted by Musescore as a legitimate, valid chord notation.
An attempt to figure out what it really means - using the Musescore "Materialize chord" option -
yields the E-G-A combination, as depicted in the attached PNG.
A collegue of mine - who is a professional musician (while I am not) - now wonders, much like I do:
How come that this is the resulted chord expansion?
.
Starting with A5 - which is a perfect fifth - is obvious and well understood.
It contributes the "E" and the "A" to the materialized chord.
.
Now - the question relates to the chord extension.
The implied operation is undoubtedly "add".
As one might expect, it attempts to add the 7th degree relative to the chord root, and - due to the "-" presence - lower it by a semitone - right?
If this is the case - the added note should have been Gb, not G (?).
.
So, what does A5-7 mean in this context of the materialized chord expansion?
Did I miss something here?
A clarification will be appreciated.
Thanks.
Hillel.
| Attachment | Size |
|---|---|
| ice_screenshot_20221129-192234.png | 5.55 KB |
Comments
A5-7 is meaningless. It's like asking what "f89ew7rf" means - it's just a nonsense string f letters and numbers. I guess based n the example given that whoever invented this notation was thinking others might understand it to mean an A with an added (perfect) fifth and added minor seventh, but you'd have to ask them to be sure - it's not standard notation at all.
In reply to A5-7 is meaningless. It's… by Marc Sabatella
Thanks.
It was my intuitive reaction too.
When you type a "nonesense" string as a chord notation - say - "Hello There" - Musescore responds with a blinking "red" - notifying an error saying: "Hey - this is not valid".
.
But this is not the case here.
When you type A5-7, it is granted, interpreted as a legal chord notation and expanded it in one way or another.
.
Factually- if one types a string that DOES start with [A,B...G] - followed by "nonesense" - it is accepted as a legal chord notation and handled as such (which means - what...?)
.
Does it mean that Musescore is not aware of the valid syntax that directs chord notation?
The only validity rule which is applied is: "start with a root tone symbol".
Should this behavior be classified as a Musescore's software bug?
.
Sadly - there is nobody to ask what was the meaning of all that.
This pattern showed up several times while documenting a rather old (50 years...) folk tune.
Hillel.
In reply to Thanks. It was my intuitive… by Hillel
My understanding of A5-7 is this.
A5 means a "power chord", that is, the root and the fifth, but no third. (A + E)
A-7 means a minor chord with a minor seven, root + minor third + fifth + minor seven (A + C + E + G)
A5-7 could then be understood to be a combination of these, except that since A5 does not have a third, the "-" indicating minor third does not mean anything and could possibly be removed. A57 or A5(7) might be better ways to notate this.
In reply to My understanding of A5-7 is… by AndreasKågedal
Thanks.
I also had this conjecture in mind.
However - strangely - materializing A5(7) in Musescore results (A+E+G#).
But introducing the "-" gives (A+E+G) - namely - the "-" does have a meaning - does it?
I must admit that I am a bit confused...
Hillel.
In reply to Thanks. I also had this… by Hillel
Since A7 would have a G and not a G#, it seems a bug that A5(7) would add a G. Not a very important one since no one would normally write that. But I guess MuseScore only sees "7" as meaning "minor seventh" when it appears in its normal place right after the root & quality indications.
In reply to Thanks. It was my intuitive… by Hillel
The parsing of chord symbols is very forgiving - as long as it can identify the root of the chord, it can construct something meaningful - and thus transpose it, handle any appropriate superscripting, export it to MusicXML, play back the root at least. This isn't a bug at all but by design, to give the flexibility to use notations MuseScore doesn't fully understand and still allow them to be treated reasonably.
In this case, MuseScore does its best to make sense out what else it sees, and the 5 at least makes sense - it means a triad missing the third (so, basically, just the A-E). The "-" is understood here as meaning "flat", and even though that makes me sense when applied to the 7 (which is already flatted unless preceded by something indicating "major"), it just gets ignored. So you do happen to end up with what your example shows. But not because the parser understood that, more just by accidental really - by ignoring the "-". Someone else reading this might well guess something else, though.
With more context about the song - showing the actual melody, the preceding an following chords, others chords also to get a sense of how this particular editor does their chords - it might be possible for someone to guess better what was meant.
In reply to The parsing of chord symbols… by Marc Sabatella
Thanks for that detailed clarification.
I feel that I understand the 'state of mind'.
But it places me at a rather strange "dissonant" position.
.
Music is not my profession, though it inspires me a lot.
I spent more than 40 years in software engineering, dealing with most aspects of that profession.
There is a "common denominator" which all software disceplines agree upon:
Whenever a software processing track encounters a problem it MUST respond to it.
Either notify, issue a warning, report an error - do something...
.
I feel that this is not the case here.
There are rules for chord notation which are commonly accepted.
Some of them are formal, others are apparently "rules of thumb", originated from historical conventions etc.
Now - one introduces a "lexical pattern" that stands for a chord symbol.
The software should first parse it and approve that it matches the notation rules.
If it is NOT the case - an exception report is expected - of one kind or another.
Otherwise - on next step - the semantics of the derived chord are computed - namely - the chord is assigned with the participating notes.
.
I am aware of the fact that this description is rather schematic or even superficial.
.
Regarding chord processing - this is not Musescore's way.
Musescore's "permissive" way of chord processing may result ambiguity, vagueness, uncertainty, randomness and even errors.
What one can see empirically, is that the only criteria which are applied for approving chord notation correctness is that the symbol starts with a root chord letter [A to G].
The rest is merely ignored.
Thus - "A-foo" is OK while "H-7" is not.
A plausible comporomise should be - at least - to provide a feedback about these potential exceptions.
At the moment, Musescore will reject and "blink red" for "H-7" but accept and grant "A-foo".
Well - probably "it is not a bug" but it is definitly an incomplete behavior.
.
Just to frame things in their right proportions:
In the common cases Musescore does an execlent job in processing chords.
It computes and assigns the particpating notes, processes them in playback, exports them to XML , expands and materilizes them upon request etc...
.
I had some past experience with other products that treat chord symbols merely as a plain text.
One can write there whatever he/she has in mind.
The software is totaly indiffernt to that contents.
It accepts everything without any further notice and places it on the sheet "as-is" while not making any "real" processing at all.
.
To make a long story short:
In my humble opinion - the statement "A5-7 is meaningless" can be acceptable.
Nevertheless - it should be reflected by the software in a way that does not leave it in a questionable state.
.
Can this be added as a future development "wish list" item?
.
Hillel.
In reply to Thanks for that detailed… by Hillel
The thing is, there are not really clear rules for chord symbols. There are differences in normal between jazz and rock, differences between what was common 50 years ago versus today, differences in how chords are typically notated in the US vs Brazil, and on and on. That's why MuseScore tries to be as flexible as it can. Showing error messages for not doing it the One True Way would not be good for most users.
But, I could imagine someday there being a feature where any given user could list the specific chords they wish to consider their "personal vocabulary" and to have MsueScore produce a warning if you try to use anything outside that list.
In reply to The thing is, there are not… by Marc Sabatella
>>> I could imagine someday there being a feature where any given user could list the specific chords
Similarly - instead of a table driven feature, propose customized selectable plugins that are driven by syntax rules of choice.
HIllel.
I haven't seen a chord like the one you mentioned.
But if you just type A5 it's a powerchord. So it only contains the notes a and e.
In the A5-7 chord -the correct spelling might be A5(7) - it looks as if a seventh has been added to the powerchord, namely the notes a and e plus the note g.
In reply to I haven't seen a chord like… by Ziya Mete Demircan
I agree. A E G. Not a big deal that I agree, of course. The 7 can't really mean Gb or G#. I suspect that It was an A7 chord, but the person that used it didn't want the 5th.
FWIW MuseScore Realizes A5-7 as A,E,G, and A-7 as A, C natural , E, G.
And so does Sibelius.
In reply to I haven't seen a chord like… by Ziya Mete Demircan
>>> In the A5-7 chord -the correct spelling might be A5(7).
Sadly - Musescore interprets A5-7 as E+G+A while A5(7) is interpreted as E+G#+A.
This was my point in the first place.
Hence - it was not a matter of misspelling but something that relates to meaning.
Hillel.
In reply to >>> In the A5-7 chord -the… by Hillel
That much - A5(7) using G# instead of G - is definitely bug. But as I said earlier, not a very significant one, because while technically legal syntax, it’s also a very strange and non-standard way to write chord. More normal is A7(no3).
In reply to >>> In the A5-7 chord -the… by Hillel
I notice that at least MuseScore is consistent.
Realize A5-7, A7, A-7. They will all have G natural.
Now realize A5(7) and A(7). They have G#.
What's different? It seems that the parenthesis around the 7 means major 7th.
AM7 and A(7) render the same. As do A5M7 and A5(7).
So to MuseScore, A5-7 should have a G natural. Is that proper chord nomenclature? That might be another debate.
In reply to I notice that at least… by bobjp
It's not the parentheses themselves, it's the fact that MuseScore takes "7" to mean a b7 above the root only when it's the very first thing after the root and "quality" indication. It's special-cased there, so it means b7 only if there is no explicit quality indicator -(eg, C7) or if the quality indicator is "minor", "augmented", or "half-diminished (eg, Cm7, C+7, C07). For diminished chords, 7 by itself means bb7 of course (Co7). The idea that someone might try to put a 7 somewhere later in the chord symbol frankly never occurred to me. But in those cases, the rule being followed is, numbers refer to the major scale unless explicitly altered. We would need to put in another special exception for 7.