An odd chord expansion? / "Materialize chord"

• Nov 29, 2022 - 17:25

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.



Attachment Size
ice_screenshot_20221129-192234.png 5.55 KB


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 by Marc Sabatella

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.


In reply to 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 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 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 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?

In reply to 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.

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 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 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.

Do you still have an unanswered question? Please log in first to post your question.