Re: Embedding MusicXML in MNX

Hi Adrian, Jim, all,

Ah, but I think you are both overlooking a couple of things. I was 
overlooking a couple of things in my last post too. Time for more 
precision! :-)

*First:* The MNX embedded in the MNX would not simply be the backwards 
compatible next version of MusicXML.
It would be code that is as like MusicXML as possible, but from which 
all unnecessary accretions had been removed, and -- in particular -- 
which took a less 19th-Century approach to time (see below).

*Second: *This need not be the only (or best) way to code MNX-Common, 
but it might be the easiest way to migrate from current MusicXML. We can 
quite easily just define a "musicXML" profile, and get on with 
migrating. Maybe the "standard" profile (being defined in the Draft 
Spec) will get completely defined and used later, but that remains to be 
seen.
Its no longer necessary to stipulate <score-partwise version="3.1"> (all 
profile="musicxml" scores are part-wise) so example 1 (helloworld) would 
look like this:

<mnx> <score> *<mnx-common **profile="musicxml"**>* <part-list> 
<score-part id="P1"> <part-name>Music</part-name> </score-part> 
</part-list> <part id="P1"> <measure number="1"> <attributes> 
<divisions>1</divisions> <key> <fifths>0</fifths> </key> <time> 
<beats>4</beats> <beat-type>4</beat-type> </time> <clef> <sign>G</sign> 
<line>2</line> </clef> </attributes> <note> <pitch> <step>C</step> 
<octave>4</octave> </pitch> <duration>4</duration> <type>whole</type> 
</note> </measure> </part> </mnx-common> </score> </mnx> Time isn't 
mentioned in the above, but that's where things start to get 
interesting. :-)*

*So *Third *(and most important): *mnx-common has to use a digital 
time-paradigm* in order to interoperate well with the web, DAWs, MIDI 
and other modern software.
The changes re MusicXML proper may end up being rather drastic, but its 
actually quite easy to do, and I think the end result could actually be 
quite simple.

Here's how my MNX-parser does it:
The temporal data is measured in ticks.
The standard CWMN duration symbols each have a default number of ticks:
/1 (whole-note): 4096 ticks
/2 (half-note): 2048 ticks
/4 (quarter-note): 1024 ticks
/8: 512 ticks
/16: 256 ticks
etc. for all the duration symbols defined by Bravura.

Given a tempo, the ticks can be converted directly to milliseconds. For 
example, if a quarter-note lasts 1 second, then its ticks are 1000/1024 
milliseconds.

Ticks are *integers*, so tick addition and subtraction is always exact. 
Measures always "add-up" in ticks.
The tick-durations of duration symbols inside tuplets always have to add 
up to the outer duration of the tuplet. I use a standard function that 
returns such values.
For example, given a triplet having an outer duration of 1024 ticks (a 
quarter-note):
If it contains a quarter-note followed by an eighth note, they have 
durations 682 and 342 ticks respectively.
If the triplet-quarter having 682 ticks is further divided in 
proportions 1:2 (a nested triplet) the inner durations would be 227 and 
455 ticks (regardless of how the symbols actually look).
Using a standard function to produce these numbers ensures that 
synchronous events stay synchronous in different parts, and sequential 
events maintain their sequence.

Note that grace-notes also have ticks. They are not outside time!

Hope that helps,
James

-- 

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



Am 18.04.2020 um 18:40 schrieb Jim DeLaHunt:
> On 2020-04-18 03:11, James Ingram wrote:
>
>> It occurs to me that things could be made easier for the MusicXML 
>> community if MNX-Common was actually (the latest version of) MusicXML 
>> embedded in an MNX wrapper
>
> That looks to me like a big step backwards… or rather, a refusal to 
> step forward.
>
> My biggest hope for MNX is that it move beyond the limitations of 
> MusicXML and its compatibility requirements, to be a much better 
> vehicle for representing digital scores. Turning MNX-Common into 
> merely a wrapper which preserves the shortcomings of MusicXML seems to 
> me is negation of this hope.
>