Re: Measure-free scores

On 4/3/2017 1:29 PM, Joe Berkovitz wrote:
 >     Did I miss a use of measures? I see no musically-justified reason to
 >     add measures as a container.
 >
 >
 > Respectfully, I think you did miss at least a couple (as have the rest
 > of those on the thread agitating to get rid of <measure>):

Thanks, I appreciate the feedback, and I did miss these cases.


 > 1. Having a <measure> element allow inheritable style properties to be
 > attached to that element and affect all of its descendants. This makes
 > it very easy to render an entire measure in a different style by setting
 > a property in one places -- say, coloring it to highlight a particular
 > measure in a teaching presentation, would be as easy as applying
 > <measure style="color: red;">. Without a container, this requires a lot
 > more smarts from the programmer to determine which run of elements to
 > affect.


Sure, it would be harder to do such styling... but the "smarts" required 
to deal with measures-as-barlines rather than measures-as-containers is 
likely very similar to the smarts required to deal with highlighting a 
group of elements for teaching using non-measured music, thus making 
non-measured music harder to implement, and thus showing a preference, 
rather than just a focus, for measured music.

The "smarts" would be a loop between barline N and barline N+1, to set 
the style for elements between, so not terribly difficult.

But this also points out that you are viewing MNX as a format expected 
to be used directly, not just as an interchange format, so it makes more 
relevant the issue of making some things, and some types of music, 
easier, at the expense of of other things, and other types of music, 
which become harder.

Given the barlines, it is easy to add measure containers to data which 
has no such containers but does include barlines; given a measure 
container, it is easy to produce a linearized sequence with only 
barlines. But given a measure container, you force a special case to be 
made for music that has no measures.


 > 2. In a future where musical DOMs support interactivity, a <measure>
 > element will dispatch events whenever the user interacts with any of its
 > descendants. Consider a teaching application that asks a student to
 > click to identify the measure in which some motive occurs.

My last two paragraphs also apply as a response to this. The extra ease 
for this example is purely useful to only a subset of music, forcing 
other music into special cases.

This use case, and the one above, could be handled by applications that 
wish to use them, by having those applications add the containers of 
interest (for measured music, by measure; for non-measured music, 
perhaps there is some other container that would be useful, based on 
some other characteristic of such music).

Building in measure as a container may well make some use cases easier 
to implement... but there is a cost to other use cases and other types 
of music.

As I mentioned in one of my comments, I have not dealt with non-measured 
music, nor do I expect to.  But adding and removing measure bars in my 
software affects no other capabilities of my software... it has a 
feature to strip them out, and another to add them in.  Everything else 
works fine whether or not they are there. Admittedly, I don't handle the 
above two use cases at present, and I don't see any problem with using 
MNX with measures-as-containers as a serious problem in using it for an 
interchange format for music that contains measures.  But adding extra 
special cases adds complexity, and if enough complexity is added, then 
the standard may suffer in not being implemented because it is too complex.


 >
 > I feel this discussion has become a bit stuck on encoding compositional
 > intent. Our use cases for the CG definitely include learning and
 > teaching music, and live interaction with it, as an important (and
 > "musically justified") activity.
 >
 > Note that this applies only to cases where there are actual measures and
 > barlines in the music -- so please let's not go around on that topic
 > again. It's been noted that we have to solve the problem of music
 > without barlines/measures.


I guess this discussion serves to emphasize that:

1. MNX is intended to be more than an interchange format, but is 
actually intended for use as an internal data format for some 
applications & use cases.

2. Some applications & use cases are so focused on CWMN that the unique 
features of CWMN force multiple branches in the representation of 
notation, adding complexity that would be unnecessary for a 
representation of music semantics (notation and performance) alone.


Personally, I'd rather see a well-specified standard interchange format, 
with the fewest possible number of special cases, that could then be 
enhanced by applications to include data structures that support 
specialized use cases.  It is good to understand the use cases of 
various types of applications, and to implement the interchange format 
with an eye toward how difficult it would be to add data structures to 
support those use cases, so as to avoid building an interchange format 
that is complex, because it is including special cases for (even useful) 
use cases, to support particular features that may well be useful, but 
which are not necessary to support in the interchange format, because 
they could be trivially added by the application that implements the use 
case.


 > ...Joe

Received on Tuesday, 4 April 2017 05:50:13 UTC