Chord symbol "warning color" issues and lack of automatic reversion

• Dec 8, 2018 - 19:27
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

  • Red "warned" chord symbols export in both print screenshot mode and PDF as red.

  • Chord symbols which have turned red to warn of possible unintended input do not return to black when the character(s) that triggered their redness are removed.

  • The logic governing the chord symbols' "warning redness" is incomplete and still allows a whole lot of possible chordal non-sequiturs.

See also: https://musescore.org/en/node/279603

fakerhythm.png

Comments

• Dec 8, 2018 - 20:58

Ok, so that red marking of Chord Symbols should not make it into the PDF and should revert to black once it got changed into something MuseScore recognizes as a Chord Symbol.
And as another issue (?) more Chord Symbols should get recognized as being legitimate.

Reply

• Dec 8, 2018 - 21:31
Regression No ⇒ Yes
Workaround No ⇒ Yes
Priority ⇒ P0 - Critical

I can reproduce only some of this. Are you using the current beta, just updated yesterday? I tried all the things listed in the text within the file you included in the forum thread, and none caused problems. Upon editing a chord symbol, they became black as expected. I suspect this was fixed as part of one of the changes made a few days ago.

The one thing I can verify is that the red color is "real", not just highlighting such as the grey that is used to indicate invisible elements. If you have the Inspector open, you can see the color change from black to red or vice versa as you type. It's actually pretty cool. But yeah, maybe it shouldn't. Anyhow, that's the workaround. Ideally I think we'd use a different mechanism for this.

As for more chords being recognized as legit - like what? The parser is very lenient as it is, recognizing things that really don't make much sense and cannot be exported to MusicXML meaningfully. Basically, get a valid root in there and it's all good after that - try for instance A14bbb73 :-). However. some things people do use in place of chord symbols, like N.C., or just a / by itself, need to be handled, especially if we're going to continue making this red color "real".

Reply

• Dec 8, 2018 - 22:10

Hi Marc. Yes, this file was created this morning in the latest .4328 beta just after installing it. Same behavior was first noted on the "first" beta release. I'm running under Win7 and have seen this on two machines.

Having already noticed and identified the issue in a real-world chord chart PDF export a few days ago, no, it is definitely not a big deal to change these things back in the Inspector... but I suspect this could be a usability issue for a lot of users, and could also catch those of us with deadlines and digital distribution chains off guard.

Similar warnings like out-of-range-per-instrument-definition noteheads don't export in red as these chord symbols do, and I am guessing that this is because they're already treated similarly to invisible elements as you mention. (This again is an issue in and of itself; more experienced MuseScore users will presume based on past experience that reddened "warning" elements won't make it to print/PDF.)

Regarding the chord-flagging logic, it's not so much about what it recognizes as what it doesn't recognize. The examples in mm. 7-8, where I have a "minor major" triad and a series of chords with apparent multiple conflicting roots / no slashes, are way bigger problems than the "expressive" ellipsis that triggered my first red chord in my original real-world chart... but there's no flagging of these whatsoever. Similarly, anything that looks like an even-numbered tertian extension would get you thrown right out of any theory lecture I'm leading, but MS does nothing about them (and those very well could be pure typos worth pointing out to the editor).

Until the feature is a little more musical and contextually sensitive about what it tries to flag, I guess I'm wondering what purpose it really serves, that's all :)

Reply

• Dec 13, 2018 - 20:35

I figure it's not MuseScore's job to play theory cop (and I say this a theory teacher myself!), so I'm not really interested in quibbling over whether C7b14 is valid or not. It's more about catching complete garbage.

Meanwhile, I see in the code where we set the red color, during edit. My sense is, it should only be there during edit, and the moemnt you leave edit mode, it should revert to the normal color. That way you see the warning while typing and have the opportunity to fix, but once you commit, it's committed. That much should be simple. not sure I like the red for this, might play around.

Anyhow, one way or another I am dealing with this now.

Reply

• Dec 14, 2018 - 06:47

Thanks Marc. Totally sensible fix to the issue and much appreciated.

Also totally agreed that MuseScore shouldn't necessarily play theory cop (at least re: things like chord symbols), but my point was - if someone does enter, say, a 12 or a 14 (or even/especially something like an 8), there are very good chances it was a strict/pure typo of the sort the new-ish red warning color seems intended to point out during score editing. Personally I'd like to see MuseScore dev focus on other priorities myself, but as is, the warn-logic is a little arbitrary in its current incompleteness and that could maybe lead to a false sense of security for some users... but yeah, probably not.

Reply