"Warning color" in chord symbols and effect on PDF output

• Dec 7, 2018 - 15:45

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.


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

Attachment Size
fakerhythm.pdf 24.23 KB
fakerhythm.mscz 8.41 KB

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