Re: Measure-free scores

On 4/3/2017 9:38 AM, Michael Good wrote:
> One of the main ways that MNX differs from MusicXML is in its addition
> of hierarchy. You can see the rationale for this in the discussion of
> musical timelines in section 5.3. One of the motivations is to make it
> easier to manipulate musical content using a document object model.
>
> Moving measures out of the hierarchy in the CWMN profile would work
> against these MNX goals. We are representing common Western music
> notation here, and measures are a central concept in that system.


It should be noted that DOM was invented for browsers... a purely 
graphical oriented interface.  For browsers, a hierarchy is sometimes 
useful.... but some other things should also be noted.

One of the latest features to be released in major browsers recently was 
the "grid" feature. If you read enough about grid, you will come to 
realize that it was invented because hierarchy isn't sufficient to 
represent complex graphical layouts. Web designers have both benefited 
(in some circumstances) and fought with (in other circumstances) the 
hierarchical nature of DOM.

My point here is that addition of hierarchy may or may not be 
beneficial. While you mention making it easier to manipulate musical 
content using DOM as a goal, in the first discussions of manipulating 
notes or chords across measure containers that goal was modified to 
"simple modifications" of music, and that moving notes between measures 
could be thought of as not being classified as simple, and that notation 
programs would probably not use DOM or XML to do such operations 
internally...

Well, if addition of hierarchy makes some operations harder, and some 
easier, one starts to question whether what becomes easier is 
sufficiently easier to pay the cost of how much harder other things become.

Let's continue to focus on measures.

DOM supports "nth-child". So with measure as a container, the nth 
measure is simply nth-child of its parent.  Simple.

DOM also supports "nth-of-type". So with measure as an annotated 
barline, nth measure begins at nth-of-type( annotated barline ). Also 
simple.

For music with measures, measures are important... but for what? The 
things I've heard are:

1) code folding in XML editors. Well, if today's XML editors can't 
automatically expand or fold blocks based on "waypoints" (like, for 
example, annotated barlines), then is that a deficiency in the MNX 
standard, or a deficiency in the XML editor?

2) measure are referred to by number in printed scores.  Very true. That 
doesn't require that measures gain a hierarchical significance... it is 
a purely linear, temporal concept, one of sequence, not hierarchy. If 
barlines were removed from music (except for repeats), most musicians 
would still be able to play it, although coordination of groups of 
musicians to start from non-standard places for practice (the stated use 
of numbered measures) would be much harder. The beholder of a 
performance does not hear the barlines or measures. It is not part of 
the semantics of music, only part of the semantics of notation. The 
beholder of a performance may hear the rhythm that is partially 
notationally captured by measures and barlines, but the beholder will 
also hear the deviations from rhythm notated by fermatas, pauses, and 
similar devices.

Did I miss a use of measures? I see no musically-justified reason to add 
measures as a container.

Validation that sufficient note events occur between barlines to ensure 
that there is consistency in the notation can easily be done without a 
hierarchy.

It should also be noted that even with the hierarchical nature of DOM in 
browsers, that modern browsers include in their developr tools, usually 
called "inspector" or "element view", a feature where you can point at a 
graphical point in the document display, and be taken directly to the 
element that produced that display item, rather than being forced to 
open/close hierarchical elements to find it, and rather than being 
forced to scroll through linearized elements to it. So I find the "code 
folding" argument of little import, with these sorts of features.

Received on Monday, 3 April 2017 19:50:07 UTC