Re: MNX Proposal now Available [via Music Notation Community Group]

Terrific topic!

This thread has various "chapters", and I'll try to respond in chunks to
each one. Here, I'm responding to Dominik and Adrian.

Let's start with a big semantic question.

> 1. I would like to draw attention to a topic that has not been mentioned
> in our ongoing discussion: The concept of measures. Like MusicXML, MNX
> requires notes to be grouped into measure parent elements. Measures are
> undoubtedly an important element in CWMN and help orientation in the score,
> but there is no "musically natural" hierarchical relationship between
> measures and notes.
>
Within CWMN, doesn't every note occur either a) in some measure or b) in no
measure (if the score has no mensuration)?

I think that a) implies that there is indeed a natural hierarchical
relationship, when measures are present at all: every note belongs to a
measure.

Which leaves b). I would suggest that for regularity of the schema,
measure-free scores or passages be treated as consisting of either a single
big measure or of smaller measures with hidden barlines and time
signatures. I don't think MNX should force the engraver or the application
to do one or the other. Neither encoding is perfect, but even if we were to
get rid of <measure> in this case (because we dislike saying "measure"),
we'd have to invent some other containing element to put the notes in.
Might as well use <measure> and maybe add some attribute to indicate that
the original music is unmeasured.

>
> Consider a melody that "fits" into a 4/4 measure grid. Now we shift in
> time this melody by let's say a quarter note. It still represents the same
> sequence of notes although it has changed the metrical positions of the
> notes and we might now need additional ties to keep barlines at the same
> points in time.
>
OK, now we're getting into some interesting territory: to what extent does
MNX try to make editing operations "natural"? The definition of "natural"
is going to be troublesome...

>
> This has practical consequences: In §5.3 (Musical timelines) you state
> that parent elements should be used as containers to organize child
> elements, and that it should be easy to alter content of a MNX document.
> Most music notation editors perform score editing operations like note
> insertion/deletion on measures: For example, inserting a note into a
> measure will only affect this measure and leave following measures
> unchanged. However some editors (like LilyPond, capella, and partly Dorico)
> propagate changes to the following measures. Now if the score is chunked
> into measures, inserting a note into the MNX document would require a lot
> of restructuring by shifting notes between measures.
>
One could workaround this by grouping all notes into a single "dummy"
> measure, but shouldn't it be possible to do note insertion/deletion in an
> almost similar easy manner as you do word insertion/deletion in a text
> editor?
>
So... it's time to more carefully qualify the goals for MNX as a mutable
data structure for music. I didn't address these points in the proposal,
and I could have done better. Anyway, let me try to state my position now:

MNX is not intended to function as the underlying data structure for a
full-blown music notation editor. No encoding scheme is going to succeed at
that goal, because editors have conflicting approaches to how editing
operations are structured -- these approaches are tied into the interface
and experience design choices of each product. Vendors are never going to
agree on this stuff. And they shouldn't have to.

This business of shifting musical data in measures following edits is a
perfect example of why MNX can't succeed in this realm. Not only do some
editors not support such behavior, but those which do, do so in different
ways and preserve or destroy different aspects of the music being shifted.
For example, some attempt to preserve the original structure of tied notes,
and some do not.

Which leads me to formulate what I think is the practical goal: the MNX
schema should make *simple*, *localized* alterations easy to accomplish.
Like, for example, adding/deleting a note from a chord. Or changing the
beaming on a note. Or removing a note from a measure and putting a rest in
its place. But MNX should not contort itself in order to support particular
ideas of how editing music should work. I know Adrian would probably prefer
a harder-edge definition, but I think if we frame this as MNX supporting
"easy manipulation" rather than "easy editing", we will get the right
result.

I would note that applications that want to do fancy note-shifting, and
wish to use MNX as their underlying data for whatever reason, can still
string together simple, localized modifications to achieve the desired
result.

In summary: supporting straightforward, localized manipulation of the
document feels like a desirable medium-priority goal, provided it doesn't
make some other aspect of MNX worse.

Should the measure element really be a required element in the new MNX
> format?
>
As Adrian pointed out, if we don't have it, then we will have to have an
ironclad set of rules for determining where measure boundaries should be
assumed.

This seems like a bad idea to me for the same reason Adrian gave: different
vendors will likely fail to agree on those rules, because they embody one
program or another's philosophy of how mensuration is applied, following
changes in musical content. Part of good spec design, is avoiding design
features that will be hard for everyone to accept!

Also, it makes local processing of any one chunk of the document harder:
looking at a measure in isolation, a parser would have to consider where it
is in relationship to some known downbeat within the score.

If a score (as originally engraved) doesn't employ measures in the first
place, that's a different situation, which I already mentioned: it's fine
to pack everything into one measure just for containment purposes (and
probably mark it somehow as having been used for that purpose).


> Reading §5.3.6 (Sequences) a similar question comes up: Why should
> sequences be restricted to measures?
>
I don't think this is fundamentally different from the other questions
above, unless I've misunderstood something.

> 2. Talking about measures I have a question regarding barlines: According
> to § 5.1.2 (System notations) multiple instances of a notation should be
> encoded singly. What is your idea to encode barlines "shared" by multiple
> staves?
>
I'd say barlines should generally go in a <measure> that lives within the
<system> element, according to my thinking. (
https://w3c.github.io/mnx/overview/#system-notations). Note that there are
competing ideas about how system notations work.

>
> 3. Finally another tiny question regarding CSS: In §6 (Styling) there is
> an example with a colored note. How to write the styling of a quarter note
> with only the note head colored (stem remains black)? Would you add a new
> "note-head-color" attribute or notate the note head as a separate entity
> with the color attribute?
>
I would guess the latter: just style the <note> with a color, not the
<event>. There are lots of styling micro-questions and I think one can
always come up with some reason that one needs just one more style
property. We'll get into that at some point :-)

...Joe