<octave-shift> issues

[lemzwerg]

I'm rather sure that this has been discussed already on the MusicXML mailing list and/or forum (which was before my time, and both resources are no longer available)...

What is the 'canonical' way to encode <octave-shift>? Following the trill example given in https://www.w3.org/2021/06/musicxml40/musicxml-reference/examples/trill-mark-element/ I would expect the following.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE score-partwise PUBLIC "-//Recordare//DTD MusicXML 4.0 Partwise//EN"
                                "http://www.musicxml.org/dtds/partwise.dtd">
<score-partwise version="4.0">
  <part-list>
    <score-part id="P1">
      <part-name>MusicXML Part</part-name>
    </score-part>
  </part-list>
  <part id="P1">
    <measure number="1">
      <attributes>
        <divisions>8</divisions>
      </attributes>
      <note>
        <pitch><step>A</step><octave>4</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <note>
        <pitch><step>C</step><octave>5</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="15" type="down"/>
        </direction-type>
        <offset>-1</offset>
      </direction>
      <direction>
        <direction-type>
          <octave-shift size="15" type="stop"/>
        </direction-type>
        <offset>1</offset>
      </direction>
      <note>
        <pitch><step>A</step><octave>6</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="15" type="up"/>
        </direction-type>
        <offset>-1</offset>
      </direction>
      <note>
        <pitch><step>C</step><octave>3</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="15" type="stop"/>
        </direction-type>
        <offset>1</offset>
      </direction>
      <note>
        <pitch><step>B</step><octave>2</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="8" type="down"/>
        </direction-type>
        <offset>-1</offset>
      </direction>
      <note>
        <pitch><step>A</step><octave>5</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="8" type="stop"/>
        </direction-type>
        <offset>1</offset>
      </direction>
      <note>
        <pitch><step>A</step><octave>5</octave></pitch>
        <duration>4</duration>
        <type>eighth</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="8" type="up"/>
        </direction-type>
        <offset>-1</offset>
      </direction>
      <note>
        <pitch><step>B</step><octave>3</octave></pitch>
        <duration>2</duration>
        <type>16th</type>
      </note>
      <note>
        <pitch><step>C</step><octave>4</octave></pitch>
        <duration>2</duration>
        <type>16th</type>
      </note>
      <direction>
        <direction-type>
          <octave-shift size="8" type="stop"/>
        </direction-type>
        <offset>-1</offset>
      </direction>
    </measure>
  </part>
</score-partwise>

With Finale 27.4 I get the expected result:

However, a recent pre-release for MuseScore 4.4.1 chokes heavily:

Irrespective of the buggy vertical position issue of the ottava, MuseScore

1. doesn't seem to accept a single-note <octave-shift> (on the third eighth note),
2. apparently needs the <octave-shift> to end one note later (4th to 5th and 6th to 7th eighth note)
3. doesn't correctly display the end of the ottava line at the end of the bar.

Item 3 is clearly a bug, however I wonder about items 1 and 2. I can't imagine that MuseScore is really so buggy, so I guess I'm doing something non-standard.

Can someone please enlighten me?

@Jojo-Schmitz

[lemzwerg]

Addendum:

• A recent PR should have fixed the bug with the vertical position. It seems that this doesn't work in the pre-release I use (MuseScore-Studio-Nightly-242470506-4.4.1-be63429-x86_64.AppImage).
• Another PR tries to handle the MusicXML code exported by Sibelius (which apparently does the same as my example above – I neither have Sibelius nor Dorico for testing so I can't verify that). Apparently this doesn't work either in the pre-release.

[lemzwerg]

Addendum 2:

Using MuseScore-Studio-Nightly-242560303-master-ac76040-x86_64.AppImage didn't help either.

[lemzwerg]

Addendum 3:

I've missed previously that MuseScore needs the file to be tagged as made by Sibelius – after looking into the source code I presume it should contain

<identification>
  <encoding><software>Sibelius</software></encoding>
</identification>

however, inserting this in the MusicXML file doesn't trigger the right behaviour. What am I missing? Does the nightly 'master' build miss this code? Do I have to do something special?

[lemzwerg]

Addendum 4:

What am I missing?

I made a mistake in tagging the MusicXML file. Ottava lines in Sibelius style are properly recognized and positioned (so the abovementioned PR works correctly). However, MuseScore still doesn't display correctly octavated notes:

[cyrilcoutelier]

You might want to add a `placement` in the `direction` tag: ``` xml <direction placement="above"> <direction-type> <octave-shift size="15" type="down" /> </direction-type> </direction> ```

…

On Thu, Sep 12, 2024 at 2:09 PM Werner Lemberg ***@***.***> wrote: Addendum: - A recent PR <musescore/MuseScore#21384> should have fixed the bug with the vertical position. It seems that this doesn't work in the pre-release I use ( MuseScore-Studio-Nightly-242470506-4.4.1-be63429-x86_64.AppImage). - Another PR <musescore/MuseScore#21499> tries to handle the MusicXML code exported by Sibelius (which apparently does the same as my example above – I neither have Sibelius nor Dorico for testing so I can't verify that). Apparently this doesn't work either in the pre-release. — Reply to this email directly, view it on GitHub <#552 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJTEWGGNNYMNXODEJEJJ2DZWF76ZAVCNFSM6AAAAABODCX4VWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRSGU2TOOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[lemzwerg]

You might want to add a placement in the direction tag:

Yes, this would be the manual fix. However, it would be nice to have the correct default behaviour in MuseScore, too (see my recent comment regarding the already merged PRs).

[mscuthbert]

I don't think that you should have a start and stop adjacent to each other and use offset to position the 8va around a note. That seems to me the type of "advanced/screwy" behavior that would be needed to encode non-standard notation like 8vas that apply to only one voice on a staff. For standard usages putting the start (up/down) before the note and stop after the note would be correct.

[mscuthbert]

Your <trill-mark> which is really <wavy-line> example has little in common with the complexities of your example, since it does not reposition by <offset> - I want to make sure that you're clear on the distinction between musical time (offset/division) and page space (relative-x).

The question boils down to: does <offset>-1</offset> mean that the direction will affect the note that has already been defined in the measure or not? Here is the MusicXML description of <offset>, with emphasis added:

An is represented in terms of divisions, and indicates where the direction will appear relative to the current musical location.

The offset element changes where the direction appears, not necessarily which notes it affects.

No software seems to be coherent with what this implies for the system.

Let's first just at the last two notes and the directions around them for simplicity (it's always easier to give the simplest possible example, not something very complex), recalling that offset=1 refers to a 64th note. It has:

(Cursor is on last 8th of measure)
Start 8vb, appearing 1/64th before standard position/current cursor
Add B-below middle C, 16th note. -- display it an octave above normal (advance cursor 4/64ths)
Add Middle C, 16th note  -- display it an octave above normal (advance cursor 4/64ths)
End 8vb, appearing 1/64th before standard position/current cursor

Here both software correctly places the notes an octave higher than normally written. The difference between the software's interpretation is: What is the normal position for ending an 8vb? Is it a micron after the final note's onset (as in most 19th-mid-20th c. scores)? In which case MuseScore's interpretation of <offset>-1</offset> as not including the final note is correct. Or should the 8vb mark end after the final note's release (as in some late 20th c. scores)? In that case Finale's interpretation is correct. (Finale's interpretation has far fewer scores that support it, but it makes more sense from a "cursor placement" perspective)

I believe that the more standard way of releasing an 8va/b is after the onset of the note and not at the end of the bar, so MuseScore seems more correct here, but there can be disagreement. But let's move on (backwards!) to where I don't see disagreement.

Let's go back two more notes, and look again at the notes and their adjacent directions:

(Cursor is 3 eighth notes from end of measure)
Start an 8va, displaying it 1/64th note before its standard position/current cursor
Add an A5, but because of 8va display it an octave lower than usual.
Stop the 8va, but display it 1/64th note later than its standard position/current cursor
Add an A5.  Do not transpose it because there is no active 8va.

Here I feel that MuseScore's interpretation is more correct. The final A5, no matter what the interpretation is, should be displayed one ledger line above the treble-clef staff because there is no active 8va when it appears. <offset> affects appearance, not effect.

The appearance of this 8va could, with the current standard, favor either MuseScore (19th c./Musical interpretation) or Finale (late 20th c./Cursor interpretation), but I don't see anything in the standard that allows for the second A to be written on the staff. So I judge for MuseScore in this case.

I don't have the time to discourse at length about the earlier notes -- I think these four are enough to show the complexities and why there is an interpretation that is stronger than another.

Comparison to other directions

Note that there is an inconsistency in the use of <offset> for some directions, like hairpins, where software uses the offset to imply not only where it should be drawn musically but also where playback should start. But here too, I think we will find a lot more consistency on positive offsets than negative offsets -- I haven't systematically done a search on how a crescendo at the end of a measure of a lot of notes with an <offset>-64</offset> will be played, but I suspect it will more often have an effect at the end of the measure than at the beginning. (If we were starting a system from the beginning, we might choose to have two different tags for <display-offset> and <semantic-offset> with the latter being non-negative, but alas that is not an easy option now).

Moving forward

Given that there will presumably be a lot of work on understanding Finale 27's MusicXML output in the near future, I really want to thank you for showing this discrepancy, and urge people making MusicXML Readers to pay attention to <software> tags that have Finale to possibly parse <ottava> + (negative?) <offset> in this way. Going forward, however, I think that (1) the effective "cursor" position for ottava-stop could be better enumerated, and (2) in general emulating the MuseScore approach is presumably a better way forward.

(I now--thanks to good cross-grade pricing--own Dorico, so once I figure it out, I can try things on all the current and future market leaders, but I have not yet looked at its output).

P.S. I am sure that @mdgood is flattered at your wanting him to have a final say, and we all value his opinion and years of expertise on all things MusicXML. I of course take whenever he chooses to weigh in very strongly. However, I think we should respect his decision to move MusicXML to a community standard, retire as editor of MusicXML, and turn its future over to a community group with successive editors. In the end it doesn't matter what you decide, I decide, or Michael Good decides -- MusicXML only has weight to the extent that the community chooses to support it. So let us sit back for a bit, look at the current MusicXML documentation/spec and decide (1) what is the best interpretation according to the current spec, and (2) if that best interpretation is wonky, how should the spec and docs change? And that is for the community to decide.

[lemzwerg]

My topmost goal is to have an interpretation of MusicXML that is consistent in itself. AFAICS, today's handling of various spanner <direction> types like ottavas and wedges is not consistent, which is a pity, but we have to live with that – the ship has sailed, there are two different interpretations where <direction> elements end, and both must be supported (at least I'm going to support both cases in LilyPond's musicxml2ly converter). Thanks for making this clear in your detailed analysis.

What I'm going to discuss here are recommendations for the future that could be added to the MusicXML documentation.

Let me start with saying that I agree with your intepretation of <offset>: This element only changes the horizontal location of a <direction> (or <harmony>) object, it does not affect the notes to which <direction> is attached to (with the exception of the playback of wedges, as you mention above). By doing this it is nothing else than relative-x in disguise, resulting in a layout-dependent horizontal position. In the following discussion I'm thus completely ignoring <offset>.

Where I disagree with you is that a <direction> element should be associated with the note before (in score order). IMHO, MusicXML describes the behaviour of music objects. It does not (at least not primarily) specify side effects. In the case of <octave-shift>, MusicXML thus tells us where the ottava symbol starts and ends – and not which notes are affected by ottavation.

To quote the standard on <direction> (emphasis added by me):

For applications where a specific direction is indeed attached to a specific note, the element can be associated with the first element that follows it in score order that is not in a different voice.

There is an exception to <direction> elements right before the end of a measure. This is (more or less) discussed in #28: The 'anchor' for such elements is not the next note but rather the bar line.

This my interpretation is, as already mentioned, in analogy with the example given for <wavy-line>: A single-note ottava starts and ends at the same note, thus both the start and stop <direction> element should happen before the affected <note> element.

I am sure that @mdgood is flattered at your wanting him to have a final say, [...]

Oh, this wasn't about a 'final say', but since he was working on Finale I guess he is the best person to answer this question, which is partially historic in nature.

[lemzwerg]

@mscuthbert, your musings on 'Comparison to other directions' made me look (again) at the 'Après un rêve' example. Here's an image of the diminuendo wedge and the corresponding MusicXML code (taken from https://www.w3.org/2021/06/musicxml40/musicxml-reference/examples/tutorial-apres-un-reve/, removing all elements and attributes not related to the problem in question).

<measure>
  <direction>
    <direction-type><wedge type="diminuendo"/></direction-type>
    <offset>3</offset>
  </direction>
  <note>
    <pitch><step>C</step><octave>5</octave></pitch>
    <duration>48</duration><type>half</type>
  </note>
  <direction>
    <direction-type><wedge type="stop"/></direction-type>
    <offset>2</offset>
  </direction>
  <note>
    <pitch><step>B</step><alter>-1</alter><octave>4</octave></pitch>
    <duration>24</duration><type>quarter</type>
  </note>
</measure>

The <wedge type="stop"> element is placed before the associated <note>! The same can be seen in the documentation example for <wedge>. I find it hard to justify that the <octave-shift> child of the <direction> element should be handled differently to the <wedge> child with respect to its associated notes, so I think this supports my point of view for a future recommendation in the standard.

[mscuthbert]

When you say The <wedge type="stop"> element is placed before the associated <note> what do you see as the "associated <note>" If you mean the Bb -- I think that here that's quite justifiable -- while the convention in notation is to make the Bb be part of the graphical wedge, I don't think it's a musical error for someone to thing that the diminuendo beginning on C ends diminishing when the Bb is sounded, even if the Bb is graphically within the scope.

But I agree that all this cursor-placement w/ offset is a bit mysterious. I will say that I've been monitoring MusicXML-list (and then github, etc.) for almost 20 years, so please understand that either your question is rare and answered and we'll need to figure it out from prior discussion, or rare and explained in the docs, or rare and not-yet-settled in which case we need to take some time to settle it.

I can state for sure that your question is rare and not been discussed often enough for me to know an answer off the top of the head and that there is no giant conspiracy trying to prevent you from gaining knowledge. Your contributions to improving the system are valued, but know that just because figuring out these inconsistencies has become your top priority now, it does not mean it is the top priority of every unpaid volunteer on the project at present.

[lemzwerg]

When you say 'The <wedge type="stop"> element is placed before the associated <note>' what do you see as the "associated <note>"

The Bb, yes.

I can state for sure that your question is rare and not been discussed often enough for me to know an answer off the top of the head and that there is no giant conspiracy trying to prevent you from gaining knowledge. Your contributions to improving the system are valued, but know that just because figuring out these inconsistencies has become your top priority now, it does not mean it is the top priority of every unpaid volunteer on the project at present.

??? What are you talking about? What's the thing about a 'giant conspiracy'? What exactly are you insinuating? I've never said something into this direction. And why do you think that I want to enforce a 'top priority' on this issue? There are many other open MusicXML issues, this is just one of them. I'm accidentally working on <offset> and <direction> right now, and I add my thoughts to the appropriate issues, that's all. Please don't write such comments which unnecessarily poison a fruitful discussion.

What I do here is collecting facts, showing that 'prior art' (i.e., the standard itself) already favours a certain way of handling <direction> elements, namely the 'before' notation – I guess this is because all (almost all?) examples have been created with Finale. Thus my arguing to make this an official recommendation since we already have that. The documentation should also state at the same time that there exists an alternative, widely used but unfortunately incompatible interpretation, namely the 'after' notation.

[mdgood]

I just wanted to add that <offset sound="yes"> affect playback and listening as well as appearance.

[lemzwerg]

Good point, thanks. So all comments from both Michael and me above are meant to have sound="yes", more or less.