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

I haven't checked the project yet, but it sounds to me like the problem
here is "what do you want to save?" "music or a music score?".

If it is the first, then no measures is the best, as music does not have
measures, it is something that humans invented to organise it.

If it is the second, then having measures is the best, as humans draw
measures in their music notation and use them to organise the notes.

I bet that MNX stands for Music Notation XML, and then what you want to
save is the notation, not the music itself (otherwise you would use an
approach more similar to MIDI).

And in my experience as a programmer I also think that XML is not a very
good format to support "operations" (move a note to another measure,
etc.), only serialize and de-serialize. I think the XML should be
transformed to a object structure in memory and the operations should be
performed to those objects, then saved again. And here you can choose to
save all the XML again or replace only the one referred by the objects
that have changed, but that is a matter to decide by every software
developer (for example, my Kunkunshi Editor saves everything again as
the XML parser I use is very simple).

Regards,

Rafael López García
Tanaka & Tajima Laboratory <http://www.dl.kuis.kyoto-u.ac.jp/wordpress/en/>
Department of Social Informatics <http://www.soc.i.kyoto-u.ac.jp/en/>
Graduate School of Informatics <http://www.i.kyoto-u.ac.jp/en/>
Kyoto University <http://www.kyoto-u.ac.jp/en>
Yoshida Honmachi, Sakyo-ku, Kyoto 606-8501, Japan
Tel.: +81-(0)75-753-4957
Fax.: +81-(0)75-753-5979
http://www.dl.kuis.kyoto-u.ac.jp/~rafael.lopez/
<http://www.dl.kuis.kyoto-u.ac.jp/%7Erafael.lopez/>

El 31/03/17 a las 02:49, Joe Berkovitz escribió:
> 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