Export of @trans.diat/@trans.semi not correct?

[wergo]

When exporting a little orchestral score from Sibelius (2019 on Mac) with SibMEI (4.0.0), the pitches of the transposing instruments are kept original (i.e., sounding), but the @trans.diat, @trans.semi attributes are in staffDef as if the instruments were notated as transposed.

However, when exporting to MusicXML, it works as expected.

Test Sibelius file (testorchester.sib): https://drive.google.com/file/d/1zXBOo-tY3s2jVD28olrt4KQX658gt9_c/view?usp=sharing

With SibMEI (Sibelius set to show transposing score):

MEI export through SibMEI:

```xml Copyright © 2022-03-21 Verovio

Transcoded from MusicXML

Flöte Fl. Klarinette in B Kl. Altsaxophon Asax. Trompete in B Trp. Glockenspiel Glsp.

```

[rettinghaus]

This is interesting. It looks like the actual values for @trans.diat and @trans.semi are correct, but everything visual is wrong, i.e. written as it would sound.

[wergo]

Yes, exactly, only the Glockenspiel converts a little more strangely.

[craigsapp]

Glockenspiel has a two octave transposition down for the written score. Often the transposition is wrong in Sibelius unless the person explicitly added a glockenspiel instrument, since octave transpositions are easy to overlook.

I suspect that there is a separate attribute in Sibelius for transposing by octave, or there is an additional octave adjustment for the transposition. For example, a B-flat bass clarinet should be written up a major 9th (octave + a major 2nd), so that would be a good test instrument to see which of the two cases is happening.

[ahankinson]

Related:

• 11

• https://music.stackexchange.com/a/4709
• Commit message on 35abc2ad47c25834ad0d2544da5f8144d40fee97

• 81

• 138 (PR adding trans.semi and trans.dia)

[ahankinson]

I'm trying to remember this -- I think what happens is that you have to choose between the encoding being correct (e.g., the notes are encoded in the correct octave) but visually incorrect (leger lines) OR the visual appearance as correct, but without the correct octave.

Your MusicXML export may look correct, but it's incorrect in its encoding -- As @craigsapp says, the glockenspiel plays in the 7th octave, not the 5th. It also loses any indication that it's a transposing instrument in the staffdef of the MusicXML file.

How are you rendering the MEI file? Is it possible that Verovio doesn't understand the trans.diat and trans.semi attributes? If it did, it could automatically adjust the rendering of the notes to have the correct visual display while still keeping the correct encoding.

[wergo]

@ahankinson thanks for clarifying.

So, the Glockenspiel in the sib-->musicXml-->MEI file lacks trans.diat="0" trans.semi="24" in staffDef. However, the exported musicXml file contains information about the transposition through an octave-change element:

  <transpose>
     <diatonic>0</diatonic>
     <chromatic>0</chromatic>
     <octave-change>2</octave-change>
    </transpose>

This should be imported by Verovio. I will raise an issue there.

Is it possible that Verovio doesn't understand the trans.diat and trans.semi attributes?

No, it does understand them. When exporting the MEI to MIDI, the sounded pitches are adapted using the @trans attributes. The visible pitches should be the notated ones, not the sounding ones (https://music-encoding.org/guidelines/v4/content/cmn.html#cmnDefs).

[ahankinson]

I'm still not sure how you are rendering the first example (the one with the Glockenspiel on the ledger lines). Sibelius doesn't do MEI import, so it must be Verovio? Or am I missing something?

[annplaksin]

@wergo At least according to the Reference Book, att.transposition within <staffDef> should be available in Verovio

[wergo]

I'm still not sure how you are rendering the first example (the one with the Glockenspiel on the ledger lines). Sibelius doesn't do MEI import, so it must be Verovio? Or am I missing something?

Yes, I am using Verovio for both renderings. The first one from sibMEI export; the second one through musicXML.

[wergo]

@wergo At least according to the Reference Book, att.transposition within <staffDef> should be available in Verovio

Yes, Verovio correctly imports <transpose><diatonic> and <transpose><chromatic> from musicXML; we would have to add <ocatve-change> there, but this is not related to sibMEI.

[rettinghaus]

We have nothing directly comparable in MEI for <octave-change>. From the MusicXML description I think this would basically be something that applies to the clef (see also https://github.com/music-encoding/music-encoding/issues/440). But we also can change the MusicXML import in Verovio to translate this to @trans.diat and @trans.semi.

[rettinghaus]

But the main issue here is with SibMEI, isn't it?

[wergo]

But the main issue here is with SibMEI, isn't it?

Yes, absolutely.

[ahankinson]

So what should the value of @oct be for the glockenspiel?

[th-we]

Sibmei exports sounding pitch⁽*⁾. Sibelius is distinguishing between "sounding (concert) pitch" and "transposed pitch".

But "sounding pitch" or "non-transposing" is not fitting terminology here because both modes are in fact transposing – as is the case for the default Glockenspiel:

Written middle C would have to sound as C4 to be truly non-transposing. In lack of a better term, let me use the slightly less non-fitting term "concert pitch".

What would be the right things to do IMO:

• @trans.diat and @trans.semi by definition tell us how we can derive sounding pitch from written pitch. I conclude that if we supply those attributes, we must encode written pitch – be it "truly" transposing or concert pitch.

• We are using the wrong values for the @trans.* attributes. When encoding concert pitch, we have to use Sibelius' ChromaticTranspositionInScore and DiatonicTranspositionInScore instrument properties, not ChromaticTransposition and DiatonicTransposition. Otherwise we'll calculate the wrong sounding pitch when applying @trans.* as specified.

• We should probably encode (truly) "transposing pitch" if that's the way the score is displayed (Edit: I mean displayed in Sibelius).

⁽*⁾_{At least mostly. When there are <octave> lines, the encoded pitch is not the actual sounding pitch.}

[wergo]

So what should the value of @oct be for the glockenspiel?

oct="5" to reflect the written pitch, and adding @trans.semi="24" to define the sounding pitch.

[ahankinson]

... or oct="7" for the logical encoding, and subtracting @trans.semi="24" to get the written rendering?

[ahankinson]

The argument being that the note is, independent of sounding or written, functionally in the 7th octave (as in, any other note written in the 6th octave in another voice, the note sounds in the octave above, rather than in the octave below).

[th-we]

... or oct="7" for the logical encoding, and subtracting @trans.semi="24" to get the written rendering?

That's not how I read the specification of @trans.*.

Also, @pname/@oct are specified to encode written pitch. We could additionally write @pname.ges and @oct.ges for sounding pitch, though that would be redundant with @trans.*.

[craigsapp]

Yes, what @th-we said. MEI usually encodes written pitch (for transposing scores) and then transposes the data when creating MIDI (or to create a sounding score). Humdrum usually encodes the sounding pitch, and then transposition is applied to get the written pitch.

Here is an example where there are four instruments that have the same written pitch, but different sounding pitches:

Notation generated with verovio:

Click to view MEI translation of the Humdrum score

```xml