Rethinking spanners and number levels

[rpatters1]

After digesting the solution for #320, it occurred to me that I should at least float an idea for another way to do this. Since the goal of mx::api seems to be to create semantic abstractions for musicxml data, a cleaner way to handle spanners might be to model them the way mnx, MuseScore, and (to a great extent) Finale do. (These happen to be systems I am familiar with.)

That is, the client would store everything about the spanner in the spanner data for the starting note. This would include the measure and tick position where it ends, and/or the end note when necessary for some spanners. This approach has some obvious challenges.

• how to identify the end note
• difficult to roundtrip with identical numberLevel values

It is such a foreign concept to musicxml that I did not suggest it in my original issue. But I've been biting my tongue ever since. It looks like the current solution will work, but I finally decided to throw the idea out to be considered.

[webern]

That does sound like a better model, overall. I'll give it shot at some point.

[rpatters1]

After reading Claude's assessment, I am wondering could we somehow leverage the optional ID field on note for specifying slur/note-attached endpoints. This is exactly how MNX does it. (MNX uses ID values much more intrinsically than does MusicXML, so slur endpoints must have ID values in MNX.)

In this scenario, every note that is the endpoint of a spanner would have to have an ID. Since ID values are immutable and unique, there is no issue around later inserts into tables. Plus, it would make a lookup table much easier, as described in #296.

Of course, this throws a wrench into the read side of things, since ID values are not required. Every endpoint note would have to be assigned an immutable and unique ID that didn't have one already. So perhaps rather than using the actual ID field, each note should carry a virtual immutable ID that the writer does not write. I am thinking out loud here while realizing that this approach has a lot of challenges.

As an aside, if ID values were available in mx::api, I would be using them a lot more right now. A structured ID can tie a musicxml entity back to a Finale entity, which makes debugging easier.

The MNX ID fields that I currently populate are

• note (with an ID value that directly identifies the corresponding musx note)
• part
• part measure
• a few others not applicable in MusicXml

I would probably assign ID values for those three in the MusicXML export, if mx::api supported them.

[webern]

I don't think that mx should write artifacts into the MusicXML in support of its own algorithms or data representation. The ID field you speak of should be left for client use.

There may be some other way to identify notes though, like an address of part index measure index voice tick time position. Maybe call that a slot then the address is the index within the slot (just a made up idea).

[rpatters1]

I definitely agree about not writing synthetic IDs into the xml.

[rpatters1]

An ideal solution would nevertheless be to supply a unique ID for every note. The reason giving it to the client is a good idea is that the client almost certainly knows the target note when as soon as it encounters the start of the spanner. It doesn't have to wait to emit the end note to know it. (This is certainly the case for both Finale and MuseScore.) And the client also knows how to construct a unique ID for the note.

I'm not suggesting these id values would serialize into the xml. But they could be internal tracking values that would be immutable no matter in what sequence elements are added to arrays.

Merging this with necessary work on the reader side probably complicates the picture. I'm solely focused on the writer. 😅

[webern]

I misunderstood this:

we somehow leverage the optional ID field on note for specifying slur/note-attached endpoints.

I thought you meant a field in the XML.

Still, I'm a little bit wary. As you mentioned, the reader would need to do this and it does not know the end-point of the spanner until it encounters it. But also, I can imagine certain writers generating music in a way where end points might not yet be known.

btw my idea above of an "address" certainly doesn't work on the same grounds because it would be even more difficult to know that ahead of time.

I think if we boil this down to a requirement, instead of proposing it through the lens of an implementation... I think the requirement is:

Requirement:

As a user of mx::api, when authoring a document and creating a spanner, I want to specify the spanner's start and end points in the same operation (hard-to-word-this-next-part) at the time when my program state is focused on the spanner start.

There may be a further constraint/request that...

Stronger requirement:

I also want this to be possible even if the endpoint has not yet been added to the score.

Does that capture it?

[rpatters1]

Exactly