Allow exporting scores without invisible items.

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.

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!

Regards,
Haipeng

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!

Haipeng

@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.

Haipeng

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.

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.

@hhpmusic, what about the "notations" tag? Why wouldn't that work?

It works only for those with notation tag, but how about hidden direction tags such as texts, dynamics, ottava lines, pedals and hairpins?

I have opened https://github.com/musescore/MuseScore/pull/8273 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.

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.

Haipeng

@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}"
    else
        local maxlines="${lines2}"
    fi
    git diff --no-index -U"${maxlines}" "${file1}" "${file2}"
}
 
unified_diff_full invisible-included.xml invisible-excluded.xml > invisible-diff-xml.txt

@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?

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.
Haipeng

@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.

OK, I'll update the pull request within the next days.

Mixing print-object yes and no still needs multiple instances of notations entry. It';'s impossible to set individual print-object values in one notations entry.

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?

Thank you for the update. Hidden tuplets are fine when exporting, the bracket and number are turned off in the Musicxml.

Fixed in branch master, commit 250fd0cc70

fix #281007: MusicXML export: allow exporting scores without invisible elements

Automatically closed -- issue fixed for 2 weeks with no activity.

Seems to work in current 4.0 nightly built with the exception that hidden staffs are still exported

Hidden staff is another kind of subject.