-
Notifications
You must be signed in to change notification settings - Fork 16
Description
Sibelius has a weird way of dealing with octavating clefs. They are merely visual. On the logical level, they behave exactly the same as non-octavating clefs. Changing from octavating to non-octavating clef (or vice versa) has no influence on the pitch of notes or their position on the staff.
In the following example, the two marked g's have Pitch
properties 43 and 67, i.e. they are 24 semitones apart, although they should be 12 semitones apart.

Now, for "instruments" that typically use octavating clefs, Sibelius already achieves the correct pitch by transposing the entire instrument. We copy that transposition to the <staffDef>
, which actually results in the wrong pitches in the MEI. In the following example, the first Tenor g has oct.ges="2"
, which is wrong. It should have oct.ges="3"
.

The g following the clef change to bass clef should be the same g as in the Bass part, but it's notated an octave too high because the entire instrument is transposed.
To clean up this mess, we probably have to consider three things:
- The global transposition we encoded in the initial
<staffDef>
. We should also re-consider what transposition we encode if the staff also starts with an octavating clef that matches the instrument's transposition. - The transposition of the current instrument
- The transposition of the current clef
Those three values have to be used to calculate new Pitch
and DiatonicPitch
values for encoding every note's pitch.
Retrieving the current clef and the current instrument can be done with the GetClefAt()
and GetInstrumentTypeAt()
methods. However, doing that for every note is rather expensive. It is probably a good idea to have a lookup structure and track Clef and InstrumentChange objects.
As long as we didn't implement a solution to this problem, there a workaround when changing clefs result in pitches in the wrong octave. Where clefs change between octavating and non-octavating, an instrument change can be added that changes the transposition. As far as I can see, this solution will result in a proper encoding with and without an implemented fix. Depending on the decision what transposition to encode based on the initial instrument type and clef, the encodings might differ slightly, but they would both result in the same visual appearance.