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

@James

I fully agree with the idea of avoiding having deal with rational numbers,
but in my opinion duration should not be specified in absolutes units (i.e.
milliseconds), but in relative units because real duration will depend on
playback tempo.

If we consider a quarter note at 60bpm it will last for 1sec. So if MNX
assigns an arbitrary duration of 1000 units to standard quarter notes, each
duration unit will be 1 millisecond but only when played at 60bpm.

I very much support the idea of using integer durations with a unit that
allows great time resolution (i.e. 1 millisecond or lower) but I think that
these units should be relative to tempo, either the tempo specified in the
MNX file or, if not specified, to a default reference value.

As notes duration progression is in a power of two, my suggestion would be
to assign 1024 units (or greater: 2048, 4096 ...) as default duration for a
standard quarter note.

Cecilio

On Tue, Mar 28, 2017 at 7:11 PM, James Ingram <j.ingram@netcologne.de>
wrote:

> @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
>
>
>
>