fix rests

[rettinghaus]

This PR

• removes the unavailable visible attribute on rest

[rettinghaus]

Test file: rests.zip

[annplaksin]

@rettinghaus @cue should be used for small symbols? Maybe I didn't get any hint by reading the documentation for using this:

Attributes that describe "cue-ness".

I'm sorry that I didn't know any better. It would have been easier if someone would have informed me.

This change would as well make it neccessary to rewrite two tests of my MEI 4.0 update, since I tested for @fontsize. As well, the encoding would need to be adjusted for notes as well. See commit https://github.com/music-encoding/sibmei/commit/ee9c69d4b30ebc57c172ff8e26a5c25ca9a621cf

Adjusting the existent test shouldn't be a huge task. Just the attribute that is tested for, must be changed. @th-we & @rettinghaus Should we adjust the test or make a new one for the rests in general, that includes a test for @loc. For the latter, I would appreciate a description of the expected output since it doesn't make sense to write a test that fits the actual output.

[rettinghaus]

I just guessed, that CueSize implies, that this note is a cue note. We don't have @fontsize="cue", and what would you do with GraceNoteSize and CueGraceNoteSize? If we'd prefer to you fontsize, it should take the values from CueNoteScale and GraceNoteScale as data.PERCENT, instead of data.FONTSIZETERM. What's your take on this @th-we @ahankinson ?

[th-we]

I agree that the @cue attribute is horribly underdocumented. The only @cue sample uses it to mark notes as "cue size" notes, not as cues from another instrument (but one'could argue about that). Verovio agrees in the MusicXML import. MusicXML can distinguish if a note is actually a non-played note or just a small note, but Verovio treats them the same and uses @cue for size rendering.

If @cue should actually only be used for non-played cue notes from another instrument, we can't write it because Sibelius' CueSize is just a visual attribute that makes objects smaller.

In any case, @rettinghaus' suggestion to write more precise @fontsize attributes makes sense.

[th-we]

Other places where @cue is only discussed/used for size:

• https://github.com/music-encoding/music-encoding/issues/509#issuecomment-384225530
• https://github.com/music-encoding/music-encoding/issues/558

But this is the discussion that lead to the addition of the @cue attribute, saying that it was meant to separate "small-ness" from "cue-ness":

• https://github.com/music-encoding/music-encoding/issues/433

Discussion related to the issue above:

• https://github.com/music-encoding/music-encoding/issues/406

I see a discrepancy between the attribute's apparent intent and its actual usage.

[th-we]

I raised this as an issue on the schema repo.

[rettinghaus]

Should I return from @cue to @fontsize?

[annplaksin]

I remembered again why I chose @fontsize... because @size="cue" is transformed into @fontsize="small" in the mei30To40.xsl in the endoding tools, see https://github.com/music-encoding/encoding-tools/blob/64db706d578bf4fba6fd67158aa21cc768ac1ea6/mei30To40/mei30To40.xsl#L1969

Anyway, is there another chance that a note might be small or cuesized apart from being a cue note´? Because we have the situation with sibmei, that we should not assume a logical interpretation for a visual feature when there is the chance of e.g. using using small notes for something other than their cue-ness...(to use that woderful word) Since @size="cue" is a visual attribute, I would prefer staying in the visual domain and go to @fontsize... except it is 100% clear and totally obvious that this note must be a cue note.

[th-we]

While there are small notehead styles to make heads smaller:

This does not affect accidentals or beams. To create something like cadenza-style runs of notes, there is to my knowledge no alternative to cue size notes:

(http://ks.imslp.info/files/imglnks/usimg/6/6e/IMSLP00016-Beethoven,_L.v._-_Piano_Sonata_16.pdf)

So yes, CueSize needs to be used in cases where the notes are not actually cues.