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

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

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.


>
> 2. More than one instrument in one part? This is possible in MusicXML and
> causes problems (Crossreference tables and complicated decoding). I think
> that it would be better to say: One part = one instrument. Some definition
> like "<printout>1,2;3,4</printout>" should make the score look as usual and
> merge instruments and voices. An example of this in MusicXML is
> "Telemann.xml", with <backup>, <forward>, <tie> and <tied> to controll this.
> (Excerpt from "Liebe! Liebe! Was ist schöner als die Liebe?"
> https://downloads2.makemusic.com/musicxml/Telemann.xml)
>

This certainly needs to be dealt with since it's a very common thing. But I
think this question should be deferred to a later stage when we've made
more decisions about the basic framework of MNX.

As a matter of philosophy I'd expect that there would be no need for
backup/forward, etc. to handle such cases. Offhand I would think that
instrument changes could be handled as a type of direction that occurs
within some measure of a part, much like a tempo change. But I haven't
conferred with Michael yet to learn enough about the motivations behind the
present design, and I am sure he and Daniel have some thoughts on this.

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


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.)


>
>
> 4. A <move>-declaration to move cursor? Specify some notes with duration
> and use <move> to step the time. And get rid of <tie> and <tied>?
> In case the notewriter wants a note divided there could be a command like
> <ties>24,24,24,24</ties> for a note of duration 96 to divide it into four
> notes with ties.
>

If there are four notes with ties, I feel the encoding should specify four
separate notes with [three] separate ties. This was the composer's intent
and it is the simplest way to represent it. Also, each tie may have
individualized attributes or styles (color, perhaps).

In a way, you may be framing a choice between an encoding that is optimized
for rendering as performance (duration-based) and one that is optimized
towards semantics and presentation (note-based).  I'm pretty firmly
convinced that semantics and presentation together carry the day, and
implementors will need to aggregate tied notes for performance purposes.


>
> 5. Should the score not be divided into parts? This could be done by using
> notes including the part number - compact note values:
> "<note "2Cb4:flat:6"/>"
> be part=2, pitch=Cb, octave=4, accidental=flat, duration=6?
>
>
Such an approach is not needed, because each note is included in an overall
<part> element. Parts are not interleaved.

About the other information: as an extreme position, it is of course
possible to smash every possible attribute into a single string
("C#4-flat-8th-grace-cue-staccato"). We have to draw the line somewhere. I
proposed that we condense pitch into a compact string, for the reason that
it represents a very strongly related package of related information (step,
octave, alteration). The other bits are optional and do not belong to this
package, so XML attributes and element provide a cleaner way to separate
them.