"Warning color" in chord symbols and effect on PDF output
If one takes some occasional expressive liberties with chord symbol input, the chord symbol turns red as a warning that something non-conventional and possibly incorrect or unintended is afoot. That's all well and good, but if one chooses to ignore the warning and goes ahead with PDF export or in-MuseScore screenshot grabs, the output on those symbols is still red.
It's easy enough to fix this by selecting the affected chord symbols and changing the color back from the auto-pushed warning-red in the Inspector. However, users might not notice this issue until it's too late and they've already distributed the affected scores / charts to their players.
I've occasionally had MS2.x kick out blue elements when I've asked for a manually-bounded screenshot with an element still actively selected, but I think this got dealt with a long time ago. The warning colors on bizarro / unexpected chord symbol input seems to be a relatively new or post-3.x thing, because I use a lot of "expressive clarifications" like this in my chord symbols for our in-house rhythm charts, but have not had this issue to date.
It would be nice if there were some way to keep the intended-helpful metacommentary separate from the PDF output without further manual intervention, just as a note out of range for a defined / selected instrument displays in red only on screen and not in MS's PDF output.
Comments
Please share a score showing this
In reply to Please share a score showing… by Jojo-Schmitz
Here's one I just threw together super-quickly as an example using the very latest .4328 beta. The red output is in both the screencap (captured directly inside MuseScore) and in the PDF (also exported directly inside MuseScore). (Edit: re-exported the screencap using print mode instead of screenshot mode.)
Everything red here turned red automatically on entry or subsequent editing of the chord symbol as usual. A couple things that are interesting about the present "warning logic:"
Anything other than letters A-H, #/b, integers, or parentheses will seemingly trigger chord-redness.
Other than an entered character outside the accepted array of characters for this element class, there does not seem to be much additional governing logic in whether a chord turns red or not. Naming two conflicting roots, two conflicting base triad qualities, or throwing on nonsense tertian extensions does NOT trigger redness. The usefulness of this feature in proofreading, accordingly, currently seems pretty limited and/or questionable.
Once a symbol turns red, it will not automatically revert to black once the characters that triggered the redness are removed. A user will accordingly need to know to look in the Inspector and apply changes manually to all affected symbols to get the score back to monochromatic.
In reply to Here's one I just threw… by dt5rb
OK, interesting, a new feature I wasn't aware of. It seems to make those Chord Symbols in can't parse as such (and so would fail to transpose, if need be).
But you can turn them black via Inspector, select and then in Inspectore use the reset button for the Element's Color. Indeed it should do that automagically though, feel free to report in the issue tracker.
In reply to OK, intersiting, a new… by Jojo-Schmitz
Will do. Again, it's not a big problem for me to change colors in the Inspector, but I can see this being a problem for students and etc. who are new to MS, notation software, and/or deeper software tweaking generally.
In reply to Here's one I just threw… by dt5rb
Done in #279666: Chord symbol "warning color" issues and lack of automatic reversion