Change part-measure objects to use separate arrays for clefs and sequences

[adrianholovaty]

In my work to update the mnxconverter to output JSON instead of XML, I realized the current approach of encoding measure contents into a heterogeneous list (containing clefs and sequences) has started to feel awkward. I brought this up in the latest co-chairs meeting (see here), and the three co-chairs agreed it's worth simplifying the encoding.

This pull request addresses that. The specific changes are:

• In the part-measure object: instead of a "contents" key that contains clefs and sequences, we now use two separate keys, "clefs" and "sequences".
• That "clefs" key is a list of positioned clef objects, each of which has a clef and position. The position is currently encoded as a two-element array, where [1, 4] would be a quarter note's duration into the measure.
• In a positioned clef, the position is optional. If not provided, the position should be interpreted as zero (i.e., the start of the measure). This is a small nicety to make the common case simpler to encode.
• Clef objects no longer require a "type": "clef", and sequence objects no longer require a "type": "sequence". That's because these two types of objects are no longer used in a heterogeneous context. (I see this as a big win, as the "type" thing always felt inelegant!)

I've updated all example documents to use the new syntax. Use this link to view the examples in context of this branch.

Community members, please have a look/think about these changes, and let me know your feedback! Personally I'm feeling very good about it.

One aspect I'd specifically like feedback on is the new "position" type. I used a simple two-element array because it's nice and compact — but a proper object might be a better approach here.

[clnoel]

My only problem with this is the strange edge-case that a clef ends up in the middle of a "zero-time" sequence, like a grace-note run (See https://github.com/w3c/mnx/issues/45 ). Also, to make sure they behave properly in the middle of a beam, or when they should only apply to a sequence. (See https://github.com/w3c/mnx/issues/96 )

I haven't looked through this carefully to see if it can cover it, since I'm swamped at work right now, but I wanted to make sure these edge cases weren't lost.

I would almost rather that the clef be given an "appears before note-reference-id" location, rather than a timed location. At the very least, they need a "staff" number.

Thanks, Christina

[williamclocksin]

Yes, I also have a worry about the corner-cases. In general, I like the design principle that elements aren’t constrained unnecessarily. So, in Calliope, clefs and time signatures and barlines etc are treated like any other staff object but just don’t have a time value. It is up to the formatting algorithm to detect when the clef etc is encountered and to position it accordingly taking the timed objects of all the voices into account. Kind regards, William--  (from mobile phone, so forgive brevity)  William ClocksinOn 18 Sep 2023, at 18:26, Christina Noel @.***> wrote: My only problem with this is the strange edge-case that a clef ends up in the middle of a "zero-time" sequence, like a grace-note run. (See #45 ) also, to make sure they behave properly in the middle of a beam, or when they should only apply to a sequence. (See #96 ) I haven't looked through this carefully to see if it can cover it, since I'm swamped at work right now, but I wanted to make sure these edge cases weren't lost. Thanks, Christina

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[adrianholovaty]

@clnoel — Thanks, that's an excellent point about clef changes within a sequence of grace notes!

Using "appears directly before note-reference-ID" would be a reasonably good solution. The only other option that comes to mind is using a numeric index, like "appears directly before the third event in the sequence," but that's problematic due to nested events (tuplets and grace notes), plus it's more brittle. Are there any other possible solutions for this?

[clnoel]

The only other solution that comes to mind is to attach a clef to a sequence, with the understanding that it always occurs at the beginning of the sequence. Any time you need a clef change you stop your sequence and start a new one. This has the side-effect of deciding that a clef is always associated with a sequence, though, which I'm not sure we want. And we'd have to delicately define how sequences of grace notes either stack or become sequential.

--Christina

[cecilios]

In this example from Claude Debussy "La Danse de Puck" there is a clef associated to a sequence:

Reference taken from Donal Byrd “Gallery of Interesting Music Notation”, http://homes.sice.indiana.edu/donbyrd/InterestingMusicNotation.html

[mscuthbert]

I am thinking about how parsing will work with all these elementIds appearing before the element itself is encountered. We may need to have guidelines for implementers.

[adrianholovaty]

Thanks for everybody for the comments! I've updated the branch to remove the "position" key, which clearly needs more thought and discussion. The good news is that this only affects inner-bar clef changes; any clef at the start of a measure can be encoded by simply not adding a position.

In the interest of moving this forward, I'm going to merge it and create a new issue for encoding inner-bar clef changes. That will also help simplify my current work in getting the mnxconverter tool up-to-date with our latest spec.

[adrianholovaty]

Just a note that I've opened issue #313 to have a more narrowly focused discussion on inner-bar clef changes.