Allow exporting scores without invisible items.

• Jan 1, 2019 - 04:27
Reported version
S5 - Suggestion

I've been working with blind musicians the past couple of months to make scores they can transfer to Braille. One problem with this is that invisible items are transferred to Braille and there is no easy way to skip them without going through either the XML or score and removing all invisible items. There are currently options to omit system and page breaks. It would be a big help to blind users to be able to omit non-visible items as well. This will make a lot of scores that are currently on easier for them, and make it easier to create a score that is both easy for the blind to use and has proper playback created using invisible items.

I know accessibility is a priority to many of the contributors and I hope this feature will be made an appropriate priority so it will end up in one of the next few updates.


This should be fairly trivial to implement for most elements, but it will require a bit more thought for others:

  • Invisible notes will need to be replaced with rests so that the measure remains the same length.
  • Measures with invisible time signatures will need to be converted to irregular measures, or the time signature exported anyway.

Invisible key signature will also require some thought, but I imagine they are quite rare anyway.

In reply to by shoogle

Voices will no doubt be the most problematic item with this option.

Concerning invisible notes. If everything in a measure in a given voice is invisible, the voice should simply not be exported in that voice.

I'm not sure how it exports, but in measures with multiple voices with rests that have been deleted or invisible, they should both be exported the same way. The most useful for Braille conversion would be if the invisible rests not in voice 1 were deleted not exported and deleted rest not in voice 1 remain deleted. I'll consult with a blind user to confirm this and report back if I'm wrong.

In short order after reading about invisible time signatures being very rare I ran across a place where they are needed.

On page 73 of Debussy's nocturn I found a place it would be irrational to not use an invisible local time signature. Prior to this, the entire orchestra is in 12/8 time.

The Soprano (Sopr.) is still in 12/8 while the rest of the orchestra is in Common time. This remains the case for several pages after this.

For invisible notes and rests, it's easy to deal with them in Musicxml, and sometimes they may be needed in braille, e.g., for harp glissandi, unless they are for playback. But these are easy to get rid of. The most difficult thing is hidden articulations, dynamics, ties and slurs. For hidden time and key signatures, Musicxml can handle them as and .
One workaround for Musescore program, not Musicxml, is to create a plugin to remove all invisible things. In the mscx file, there are lots of 0 fields, and if the plugin can find all such tags and delete the whole element, this will be much easier than doing xml export. But this may be a bit dangerous when meeting notes/rests. We should think of a way to make all things securely.
Currently I'm very afraid of working with existing scores which have lots of such things. I have to go to the uncompressed Musescore files and delete lots of such codes, which wastes my expensive time hours by hours! There are lots of good scores like Wagner's opera excerpts, but I'm frightened and can't do them in braille!


A final confirmation for Leon or others to deal with:
1. It's of no problem to keep hidden notes and rests exported, because they already have the print-object="no" attribute;
2. For hidden time and key signatures, the same attribute will work too, so are ok to export;
3. The hidden articulations, symbols, dynamics, metronome marks and texts should definitely be excluded during Musicxml export, for they have no such an attribute, and the re-import will then generate lots of unwanted things. It will also harm braille transcription, except we use special script to remove these nodes. This is the only point the developers should do. Thank you!


@hhpmusic, thanks for confirming!

  1. That's good because it would be tricky to exclude notes and rests without corrupting a measure (i.e. the number of beats would no longer add up to the time signature).
  2. Also good for the same reason.
  3. It should be possible to exclude these things (i.e. articulations and text, etc.) without impacting anything else.

So in summary, very good news indeed!

Dear Leon,
Is this one easy to implement? Just filter out slurs, ties, dynamics (including hairpins), pedal symbol and lines, metronome marks and texts. Generally, all playback-related non-note information should be filtered out when exporting. Notes, rests, key and time signatures can be exported with print-object="no", as Musescore behaviors now.


Regarding (3) from @hhpmusic's comment above, it looks like many elements that don't have the print-object="no" attribute (e.g. articulations, dynamics, etc.) can appear inside a <notations> element which does have this attribute (see the MusicXML manual for notations. This might provide a way for us to hide those elements without having to exclude them entirely from the XML output.

If that fails then the another option would be to give the hidden elements a transparent color. MusicXML uses the ARGB hex color system (where A stands for "alpha" in reference to the alpha transparency channel), so a color value of "#00000000" means transparent black. This wouldn't be ideal because MuseScore also supports transparency and uses it differently to things just being hidden, but the end result is the same of course (the item is not visible) and would allow us to keep the elements in the XML, so we wouldn't need to add an option to exclude them.

In reply to by shoogle

The transparent way should work, but I don't know if it will take room to yield blank space when importing back. Also, this only works for newly implemented braille music software. For BrailleMUSE which is stopping development, and for those who prefer Goodfeel, this may still be a problem. A better way is to export those hidden things as tags prefixed and suffixed with xml comment symbols, so that they will not be recognized by Musicxml reading software. When you want them, just remove these comment expressions.

Status active PR created

I have opened which is currently dealing with those elements exported under or tags. Such elements include spanners, texts, articulations and other annotations (unless I have missed some of them). A similar issue seems to be also present for hidden staves (see #102086: [MusicXML] Import/export hidden staves and #307530: [Musicxml Export] - Hidden staff info not exported) but I guess it would be better to deal with it separately.

In reply to by dmitrio95

you're correct, hidden objects except notes, rests and time/key signatures should be excluded from the export. The excluded items already have print-object="no" attached, and are sometimes required in braille.
For hidden staves, I've talked to Peter (Shoogle), and we agree this should be done in Musescore 4. The reason is, Musescore currently only forces empty staves to be hidden, not something written into the mscz code. It doesn't do things like Sibelius, e.g., at some pages a number of empty staves are displayed, while at other pages they are hidden and replaced by other staves. If we should imitate the original score, we have to input a transparent text into the staff of the page to display it, and this is not the right way to show such staff. In Musicxml, we have staff-details print-object="no", but what do we have in Musescore? So just leave this in our future work, which has been logged in our DAISY Music Braille Project issue list.


@hhpmusic, here's the output of Dmitri's PR. He implemented an option to include or exclude the invisible content from the MusicXML, so I have attached both versions as well as a file that shows the difference between them (look for lines starting with a minus sign '-' in the diff file to see what was excluded).

# Bash code to create diff file
function unified_diff_full()
    local file1="$1" file2="$2"
    local lines1="$(wc -l "${file1}" | awk '{print $1}')"
    local lines2="$(wc -l "${file2}" | awk '{print $1}')"
    if ((lines1 > lines2)); then
        local maxlines="${lines1}"
        local maxlines="${lines2}"
    git diff --no-index -U"${maxlines}" "${file1}" "${file2}"
unified_diff_full invisible-included.xml invisible-excluded.xml > invisible-diff-xml.txt
Attachment Size
score.mscx 25.97 KB
invisible-included.xml 20.62 KB
invisible-excluded.xml 19.19 KB
invisible-diff-xml.txt 21.62 KB

@hhpmusic, the excluded elements are: <words> (text), <metronome>, <dynamics>, <wedge> (hairpins), <pedal>. All occur in the <direction> tag, and the entire <direction> tag is itself excluded.

There are various other invisible non-duration elements (e.g. slurs, fermatas, articulations, glissandos) that have been included in both files because these elements have the print-object="no" attribute. Would you prefer these elements to be excluded even though they have the print-object="no" attribute?

As mentioned above, duration elements like notes, rests, and time signatures need to be retained in both versions (albeit with the print-object="no" attribute), and this is already the case in Dmitri's code.

@dmitrio95, I think the example files are currently missing an <octave-shift> (ottava) element which @hhpmusic mentioned above, so please can you add one of those to your tests?

In reply to by shoogle

Thank you Peter for the examples. The latter looks fine, but after an analysis, I suggest to exclude all notational elements too. The reason is, when there are both visible and invisible notational elements attached to one note, e.g., visible staccato and invisible accent, it's impossible for us to include two notation blocks in ont note entry! A direct exclusion will avoid this problem.
Also yes, hidden ottava line should be excluded. However, this is the only thing I'm not quite certain, for it will work fine in non-keyboard music, and when there's cross-staff notation with ottava lines, the other hand should add a hidden ottava line for correct playback. Removing these lines should impact the braille pitc octave location. But just exclude it, and the ottava application for cross-staff notation should be implemented at the notation side.

@hhpmusic, are you saying the MusicXML specification does not allow us to have a <notations print-object="no"> tag immediately followed by <notations print-object="yes"> tag?

Anyway, @dmitrio95, please update the exclude option for your PR so that it excludes invisible elements within <notations> tags. (Keep them with print-object="no" when the exclude option is not set as you do now.) Please also add an ottava line to the test files. I don't think the issue with cross staff notation is something we should try to solve in this PR.

I have updated the pull request to add octave shifts to test files and exclude invisible elements under <notations> tags as well. I am unsure though about invisible tuplets: they seem to be sometimes necessary to correctly restore the structure of the score (at least MuseScore's MusicXML import doesn't seem to work well without tuplet elements in case of nested tuplets). Should we also exclude invisible tuplets, or should we perhaps use their bracket, show-number and show-type attributes to avoid displaying them instead of marking the entire <notations> tag unprintable?

Fix version