Incorrect Chord Parsing & Playback for Augmented/Diminished 7th Chords using "+"/"o" Symbol
Reported version
3.5
Type
Functional
Frequency
Few
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
When using the "+" symbol to notate an Dominant 7th chord with an augmented triad, placing the "+" symbol after the 7 causing incorrect chord parsing & playback. For example C7+ versus C+7.
When the chord is notated as C7+, it plays back only the root and is parsed incorrectly when viewed using the Realize Chord Symbol tool.
Other chord symbols using other modifiers such as C9+ playback correctly and are parsed accurately.
Placement of the "+" AFTER the 7 or other modifier is very common in published scores and should work in MuseScore as it does with 9ths, 11ths, etc.
Fix version
3.5.1
Comments
Similar for C7o vs Co7
These are actually two very different issues in terms of the implementation. C7+ we do handle, at least partially, and get the right MusicXML at one point, but then don't realize we've handled it and end up marking the score not understandable. C9+ doesn't need the special MusicXML handling, so that we get right. This is an extremely easy fix, and worth it because this is not that uncommon of a way to write chords.
C7o we just don't even try to handle, because I had never seen it before when I wrote the parsing code. So we'd have to implement special handling for that. No doubt it's doable but rather more difficult, and as far as I know the number of people using this particular spelling is probably very small in comparison.
So I might propose a quick fix just for C7+ but still leave an open issue for C7o.
Or split it off into a separate issue
Not a regression though, it never did this
See https://github.com/musescore/MuseScore/pull/6460
Fixed in branch 3.x, commit 51289cb40d
_fix #309108: add support for quality after extension
The chord symbol parser was implemented many years ago
and it supports msot common notations, but a few used in some regions
slipped through the track. In particular, C7o and C7+.
These place the quality after the extension.
There was partial support for C7+, and it parsed OK,
but a bug never noticed until now is that it was also marked
as not "understandable", which now prevents playback.
This commit fixes the bug that prevented C7+ from fully working,
but adding a null handler for an empty token in the loop
during which the "+" is processed and replaced with an empty token.
It also adds the same processing for C7o._
Fixed in branch 3.x, commit 661e07495f
_Merge pull request #6460 from MarcSabatella/309108-extension-quality
fix #309108: add support for quality after extension_
3.5.1, surely? :-)
yes
Automatically closed -- issue fixed for 2 weeks with no activity.