Ottava beginning and ending (a big old mess)

[rpatters1]

I am very new here, but I am gradually working towards possibly being able create a MNX export at some point. I am a big fan of the idea of a widely accepted JSON format for music. I thought I would share some discrepancies in MusicXML in the interpretation of ottava that I discovered, because it may still need to be clarified in MNX. The basic problem is, where does the ottava end.

Where, oh where does an ottava end.

Finale exports ottava endings before the final note. That is, taking the example in the documentation, the ottava end node occurs right before the first written C6 in bar 2, even though the ottava bracket extends over it.

Based on a fair amount of testing, it appears that both Dorico and MuseScore think the ottava end node should come after the final note. If you import a Finale-exported mxl into either of those programs (at least currently), they only extend the ottava to the written E6. Furthermore, if you were to export that example from either program, you would see the ottava end nodes after the final note under the bracket. (The written C6 bar 2.)

The current Lilypond mxl import, however, agrees with Finale that it should come before the last note. I haven't got Sibelius to test what it does.

This is important to MNX, because it appears MNX is going with the before approach. If this is where it ends up, there needs to be some specific language in the spec to prescribe what it means. I have some concerns about it, especially given that the ending is only declared where the ottava starts.

• On the face of it, the ottava as currently specified literally does not include the last note. In the example, the ottava extends of the first half of the bar and therefore does not include the final note. I would not trust convention to get this right, and some people will not read whatever documentation is written. I wonder if it there would be a way to have the end object point to an event rather than a metric location.
• If the intent is for MNX to be a storage format, I wonder if the bar where the the ottava ends should not have some indication that there is an ottava. We don't want to impose a lot of backward searching. I suppose the app using MNX as its storage format could read it in and tag all that information, but that also gets back to if there are two ways to interpret something, it will be interpreted two ways.
• This is going to be a recurring issue for other kinds of note-spanning directions. It is already a muddle between Finale, MuseScore, and Dorico for some of them (at least). (I've tested exporting Finale's "custom lines", and it is a messy confusion around where their ends should occur.) Again, attaching the end points to event objects might achieve a better result.

And the beginning is not straightforward either.

The beginning of an ottava can be ambiguous as well, if there are grace notes before the first note. Finale always leaves grace notes out of the ottava when it exports MusicXML, and importing programs (I've tested Dorico, Lilypond, and MuseScore) all interpret them differently. The spec should probably specifically address this case as well.

I went down this rabbit hole because I was trying figure out how to get MuseScore and Dorico to import the following image created in Finale:

Note that in the current iteration of MNX, this would lead to an ottava that ends where it starts, no matter which grace note it starts before (or doesn't). (As it does in mxl files exported from Finale, but not those exported from MuseScore or Dorico.) That is a free-for-all, that is.

[adrianholovaty]

Hi @rpatters1 — thanks for starting this discussion.

In MNX, the ottava is definitely encoded to include that last note. (If I'm understanding your terminology correctly, it takes the "after" approach.) Specifically, an MNX ottava object's "end" points to the rhythmic position of the last note (event) that's included.

Have a look at this part of the spec for a discussion of MusicXML's inconsistency and how MNX approaches it. I also had a look at the ottava object docs and they seemed reasonably clear to me, but I'm happy to make tweaks if you suggest how it can be made clearer.

As for when an ottava starts, this should be pretty unambiguous in MNX, even in your grace-note case. You'd put the ottava directly before the first affected note. Again, I'm happy to make tweaks to the documentation to make this clearer — just let me know which parts could be clarified.

To your suggestion of changing "end" to point to an event rather than a rhythmic location: there's some precedent for this idea in MNX. Slurs (see example here) allow for specifying a specific note via its ID and a specific event via its ID.

Though I don't want to get in the habit of relitigating previous design decisions, I'd be open to reconsidering this. It's fair to say the following has a low likelihood of being misinterpreted:

{
    "type": "ottava",
    "lastEvent": "event123"
}

Any thoughts on this final idea?

[rpatters1]

Hello, @adrianholovaty. Thank you for such a detailed reply.

I agree that the spec (at least in the example) is encoded (by convention) to include the last note. But the musical span it currently defines does not. That is, the musical span runs through the first half of the bar but does not include beat 3 where the last note is. This gets tricky if a note has zero metrical value, which primarily means grace notes. (A tuplet might theoretically also create a zero-metric length note—and has in Finale—but we'll leave that strange workaround case aside.)

Grace notes tend to end up as neglected step children in these kinds of issues. I would like to see a spec that gives them full-fledged note status. They just happen to occupy zero metrical length. Any solution for grace notes would also handle corner cases involving tuplets.

Consider this example:

As far as I can tell, this example cannot be correctly encoded in MNX. (It can't in Finale either. I just made it look graphically like that.) By contrast, MusicXML can encode it, but actual implementations probably don't in many cases.

I think the suggested lastEvent approach for ottavas could solve these issues. I wasn't in the earlier discussions, and there could be negative consequences to this approach that I haven't thought about. But there are other spanning directions that will have the same issue. I think it is important to consider carefully the implications for grace notes in each case.

Like, can a hairpin affect grace notes, e.g., a hairpin swell under grace notes? Hairpins are a whole another can of worms, because they can exist with or without notes to attach them to.

[rpatters1]

FWIW: Finale allowed spanning directions to either span what MNX calls events or to span a metrical distance. In Finale parlance they are called Smart Shapes, and this was the difference in the program between "note-attached" and "beat-attached". The attachment (a separate data item from the shape) determined how it spanned. Finale's UI only allowed a choice for slurs, but under the covers it could attach any Smart Shape either way. Perhaps this is an idea we could take onboard for MNX, though I don't know how much rework it would be.

[dougheyer]

From the MNX octava shift definitiion:

"An ottava (octave shift), traditionally notated with a marking such as "8va", tells a musician that the affected note(s) are being rendered a number of octaves up or down from their normal appearance on the staff, for sake of readability."

"Note: the "pitch" attribute of any affected note should be encoded as the sounded pitch. In other words, the absence or presence
of an octave shift does not affect a note's "pitch" attribute; the octave shift only affects the note's graphical display."

I'm not sure what the MNX definition will end up being, but the above seems to be more or less consistent with MusicXML.

From a musician's standpoint and from standpoint of notation tradition, the above definition could be changed in MNX to be:

"An ottava (octave shift), traditionally notated with a marking such as "8va", tells a musician that the affected note(s) should be rendered a number of octaves up or down from their appearance on the staff."

"Note: the "pitch" attribute of any affected note should be encoded as the written pitch. In other words, the absence or presence of an octave shift does not affect a note's written diatonic "pitch" attribute; the octave shift only indicates that the true (MIDI) note should be played one or more octaves above or below the written note."

There is some confusion here:

1. what note to play to yield the true (MIDI) note vs. what note to write to justify the existence of the octave shift, and
2. in spite of repeated definitions the term "pitch", unless carefully bound within a specific context, is forever ambiguous.