Open wergo opened 2 years ago
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.
Yes, exactly, only the Glockenspiel converts a little more strangely.
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.
Related:
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.
@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).
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?
@wergo At least according to the Reference Book, att.transposition
within <staffDef>
should be available in Verovio
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 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.
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
.
But the main issue here is with SibMEI, isn't it?
But the main issue here is with SibMEI, isn't it?
Yes, absolutely.
So what should the value of @oct
be for the glockenspiel?
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.
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.
... or oct="7"
for the logical encoding, and subtracting @trans.semi="24"
to get the written rendering?
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).
... 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.*
.
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:
Transcoded from Humdrum
Preferably MEI would not implement a separate attribute for <octave-change>
, since it is better to incorporate the octave transpositions into the @trans.semi
and @trans.diat
system (by adding 12 for each octave in semi
and 7 for each octave in diat
).
But one thing in favor of preserving <octave-change>
is that it would allow you to convert back and forth to/from a sounding score: When creating a sounding score, the octave transposition instruments maintain their transpositions. For example, the glockenspiel notation will look exactly the same in both sounding and transposing scores (and will always have a two octave transposition to sounding pitch). Incorporating <octave-change>
into @trans.semi
and @trans.diat
would make conversion between sounding and transposing scores much more difficult to implement.
NB: The Dolet plugin does a lot for calculating the written pitch. We could use their code as a guide: https://github.com/MakeMusicInc/DoletSibelius/blob/main/Dolet8.plg
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:
```xmlWhen exporting to MusicXML, it looks great:
Imported MEI via MusicXML:
```xmlTranscoded from MusicXML