Re: MNX Proposal Overview - and reduction of "book-keeping and post-processing"

@Mogens: apologies for some of this being a reposting, but my first 
attempt didn't arrive on public-music-notation-contrib@w3.org. My Email 
app was configured with the wrong sender address.
My original mail crossed with Joe's reply, so I'll reply to his mail to 
keep things straight.

Mogens:
>
>     1. One pass? My program uses four passes to read the MusicXML
>     file. Could a MNX-file be read and understood by reading it once
>     from the beginning?
>
Joe's reply:
> It's not possible to give a completely rigorous answer, because the 
> answer depends on what the program does, and on your definition of 
> "pass" :-)
>
> However, I was of course interested in minimizing the amount of 
> processing needed. If what our hypothetical program does is to 
> generate an internal data structure representing semantic CWMN, then I 
> would say yes, it is practical to process MNX in a single pass.
+1 to Mogens request.

Mogens:
>
>     3. Only one value of divisions? I don't like division-changes
>     inside a part. In my program I compute a new general value by
>     analysing the primefactors in durations and change all durations -
>     and also I reduce the number of divisions (Sibelius has very high
>     divisions). The decision to do this came, when I was thinking of a
>     note starting and ending in different values of divisions and the
>     possibility that there was no timertick where the note ended.
>     Durations shall be exact - A divisions-value of 256 and a triol
>     should not be allowed, because the durations will be rounded, e.g.
>     85, 85 and 86. My algoritm fails to find common prime-numbers here
>     where 85 and 86 is really the same number.
>
>     To "MNX Proposal overview" this could be added to Section 3.2
>     Profiles after "The metrical content of a tuplet does not exceed
>     its duration":
>     Add: "The duration values must be exact." (no rounding)
>     And: "The common value of divisions value should be as small as
>     possible"
>     (No common factor exists for divisions and all durations)
>
Joe's reply:
> Divisions are irrelevant in MNX as it does not use them. Rational 
> numbers are used for all note values and time intervals, and tuplets 
> impose a time modification on their contents. Thus there is no prime 
> factor analysis problem (I'm very familiar with how annoying this is.)

I agree with Mogens, that the MNX spec should
> Add: "The duration values must be exact." (no rounding)
There's no reason to have event symbols less than a millisecond apart 
because such time intervals are literally imperceptible.
Durations have to be added, subtracted, and compared. Forcing 
programmers to round rational numbers will cause endless synchronisation 
problems when comparing the results of different additions and subtractions.
Desktop applications would be much easier to write if the durations 
start out as integers.
In Javascript, Math.round() may have to be used anyway, but it would be 
much better if the result is going to be predictable.
This means that, when machine-converting from MusicXML, the members of 
triplets (and other divisions) will often have different lengths. 
However, a) the difference will never be large enough to be perceptible, 
and b) applications can let users tweak the durations if they want to. 
Users would not be restricted to the default values created from the 
MusicXML file.

And
> "The common value of divisions value should be as small as possible"
I think the unit should be the millisecond. That's what the Web MIDI API 
uses.

All the best,
James