MNX proposal §1.2

Hi all,

I'm currently studying the MNX proposal. Here are some thoughts on §1.2:

First, I should say that I agree completely that its important
> ...to be able to machine-translate MusicXML into MNX. This is 
> essential for migration purposes.
and congratulate Joe on his first proposals. If my suggestions seem 
rather radical, that's because I'm coming from a different background. 
I'm certainly not an expert on MusicXML, so please shoot me down in 
flames if you can!

I think its a fundamental mistake to think that CMN should be treated 
differently from other graphic notations.

Correcting that mistake will have interesting consequences for several 
sections further down the proposal. This mistake has a long history, 
going back at least to the 1950s and '60s. Its a mistake the 
/Avant-Garde/ made, and failed to solve, and which lead to all manner of 
unnecessary complications in the MIDI standard during the 1980s. 
(Fortunately those unnecessary complications have been eradicated in the 
Web MIDI API.)

The key to solving this problem is to distinguish/very strictly/ between 
spatial and temporal data in MNX's markup.

The problem with MusicXML is that it was designed for sheet music, and 
sheet music contains purely spatial information. Temporal info is 
inferred from the graphics, but that is a mistake. Any temporal info 
associated with sheet music is stored in living traditions of 
performance practice, not on the page. Metronome marks are just a way to 
transfer temporal info into a performer's memory.

MNX describes computer files that are not restricted to spatial 
information in this way. Spatial and temporal info can be stored in the 
same file. So, when migrating MusicXML files, MNX has to be explicit 
about the type of the information it is describing. Is it spatial or 
temporal?

I think most of the elements in the current MNX proposal should 
initially be considered to describe objects /in space/.

For example:

<tempo  bpm="120/4"/>

just means that there is a graphical object (an annotation) telling a 
performer how to set up a metronome to discover how fast the 
CMN-conformant notation should be played. The real-time metronome info 
gets stored, for future use, in the performer's memory. Most notations 
don't have metronome marks, so this annotation should be optional. 
Performance practice is taught live in music lessons. (Metronomes were 
introduced in the 19th century when it became impossible to demonstrate 
the temporal info live to all the sheet music's consumers.)

<event  value="4"><note  pitch="E4"/></event>

just means that there is a quarter-note symbol at height "E4" on the 
staff (using the current clef), or maybe that the graphics consist of a 
diagram showing how the event should be fingered.
What the symbol/means /is temporal information that should be supplied 
separately. This <event> might, for example, be on a staff for a 
transposing instrument.

Similarly, the tuplet example at §5.3.13

     <tuplet  actual="3/8"  normal="1/4">
         <event  value="8">
             <note>...</note>
         </event>
         <event  value="8">
             <note>...</note>
         </event>
         <event  value="8">
             <note>...</note>
         </event>
     </tuplet>

just means that there should be a graphical object that looks like a 
tuplet bracket bracketing the <event>s. Nothing can be inferred about 
the <event>s' durations from that fact. The bracket is just there to 
improve legibility; to give the reader more information about the 
intended alignment of the symbols. But the temporal information should 
be supplied separately in MNX. The <tuplet> bracket is an optional 
annotation.
The default temporal information for an <event> (extracted from the 
MusicXML file, taking account of tuplets, in the usual way) could be 
stored in a <time> element inside an <event> like this:

<event  value="4"><note  pitch="E4"/>
     <!-- more <note>s -->
<time>...</time> <!-- more <time>s --> </event>

Further <time> elements could describe different temporal 
interpretations of the graphics.
A <time> element would describe all parameters that involve temporal 
units: durations, pitch frequencies, un-notated sub-events and 
continuous controller info. That's very much like my proposed 
<score:midi> element for SVG+MIDI files, but I don't know if <time> and 
<score:midi> are really identical. That's something that needs thinking 
about. <time> might, for example, somehow be MIDI agnostic.
Note that the <time> elements contain precise durations, so an 
instantiation of such a score can be played back, and we don't need a 
metronome. The default performance does not necessarily have to be in 
strict tempo. It could, for example, have /swing/. Other layers of 
<time> elements could contain timings taken from recordings of real 
performances.

I think the structure of an MNX file probably relates to the structure 
of a corresponding SVG+MIDI instantiation. MNX element names should 
translate to SVG element class names. But this mail is long enough 
already, so I'll leave that topic for another time.

all the best,
James

-- 
http://james-ingram-act-two.de
https://github.com/notator