Re: MNX Proposal now Available [via Music Notation Community Group]

Hello Joe, Adrian and Rafa,

thanks for your comments and clarifications on the measure topic. Now is 
the time of thoroughly reviewing MusicXML concepts, and that was the 
intention of my remark.

 > Within CWMN, doesn't every note occur either a) in some measure or b) 
in no measure (if the score has no mensuration)?

Well, yes and no. From a purely notational perspective, one musical note 
crossing a measure boundary is visually represented by two distinct 
graphical note objects, kept together by the tie element. From a musical 
perspective, it is still one note arranged into the measure grid. But I 
can follow Rafa's argument that our goal should be describing musical 
notation, not music.

 > MNX is not intended to function as the underlying data structure for 
a full-blown music notation editor.

No, it is not. And it also clear that the notation programs that have 
been mentioned will never use MNX as their internal data structure. But 
as more and more smaller music notation applications are built for the 
web and mobile devices, there will be growing interest in being able to 
manipulate MNX objects without using another internal data structure (it 
was obvious to me that nobody wants to modify the XML directly, so I did 
not mention that).

 > Which leads me to formulate what I think is the practical goal: the 
MNX schema should make *simple*, *localized* alterations easy to accomplish.

This is a helpful clarification of "it should be easy to alter content 
of a MNX document". The propagation of changes to the following measures 
which may be a desirable feature certainly is neither simple nor localized.

 > Should the measure element really be a required element in the new 
MNX format?

I agree that MNX should be close to the visual score, and that omitting 
measures might run into the danger of misinterpretations of the score 
representation (and require additional rules).

So if a MNX based editor would like to provide the "propagation of 
changes" feature, the practical (although not desirable) solution 
avoiding measure restructuring is using a single "dummy" measure.

 > If a score (as originally engraved) doesn't employ measures in the 
first place, that's a different situation, which I already mentioned: 
it's fine to pack everything into one measure just for containment 
purposes (and probably mark it somehow as having been used for that 
purpose).

In this case we are probably talking about music outside CWMN (like 
medieval music or Okinawan music mentioned by Rafa). Here we should 
definitely get rid of the measure element because it does not represent 
how music is notated. But for these music epochs/styles, we will need 
new score content types other than "cwmn".

Looking forward to fruitful discussions in Frankfurt...

Best regards,
Dominik


Am 31.03.2017 um 03:10 schrieb Rafael López García:
>>
>>     I bet that MNX stands for Music Notation XML, and then what you
>>     want to save is the notation, not the music itself (otherwise you
>>     would use an approach more similar to MIDI).
>>
>> Not bad, and you didn't even have to read the spec!  :-)
> But I read the one of MusicXML. And I wrote a MusicXML parser and a 
> Java-2-MusicXML converter in Android. And I may write another for MNX 
> in the future.
>>
>> Yes, this is about saving a score, which is instructions on how to 
>> perform music, as distinct from music itself.
>>
>>     And in my experience as a programmer I also think that XML is not
>>     a very good format to support "operations" (move a note to
>>     another measure, etc.), only serialize and de-serialize. I think
>>     the XML should be transformed to a object structure in memory and
>>     the operations should be performed to those objects, then saved
>>     again. And here you can choose to save all the XML again or
>>     replace only the one referred by the objects that have changed,
>>     but that is a matter to decide by every software developer (for
>>     example, my Kunkunshi Editor saves everything again as the XML
>>     parser I use is very simple).
>>
> From an informational point of view they are they are not completely 
> the same. A human-readable music score is more than the instructions 
> really needed to perform music. There are elements that are purely 
> organizational (e.g.: the measures) and others that are merely 
> aesthetic. You don't really need them to perform music, and they are 
> actually introducing a certain complexity that could be avoided, that 
> is why Dr. Hörnel argued the possibility of not having them.
>
> And actually... that is my case. When I wrote the aforementioned 
> MusicXML parser, I did it for Kunkunshi Editor, an editor of Okinawan 
> music. Okinawan music is NOT represented in the western fashion with 
> staves and measures, but with a different system called Kunkunshi 
> (工工四). So I also found all those organizational and aesthetic elements 
> completely unnecessary for my use case. And when I write the parser 
> for MNX in the future, it will happen again. But I understand that 
> this tiny and infrequent use case, as medieval music notation, will be 
> out of the scope of your standard.
>> As you say, one shouldn't use XML itself to perform these operations 
>> (and I hope no one does).
>>
>> Standard modern practice is to parse XML into memory using a Document 
>> Object Model (DOM) parser and manipulate the in-memory structure via 
>> the DOM API -- a web standard, see 
>> https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model. 
>> It can then be serialized back out.
>>
>> This practice is so ubiquitous that web programmers like me will talk 
>> in terms of manipulating the document, when what we really mean is 
>> manipulating the DOM in memory!
>>
>> ...Joe
> Yes I know what a DOM parser is, I am tired of programming them. But 
> when I read Dr. Hörnel's email it looked like somebody was opening the 
> door to directly perform operations there. I am glad you clarified 
> that is not the case.
>
> Best regards,
>
> Rafa

-- 
Mit freundlichen Grüßen
Dr. Dominik Hörnel

capella-software AG
An der Söhrebahn 4
34320 Söhrewald
Tel. +49 (0)5608-3923
Fax. +49 (0)5608-4651
E-Mail: info@capella-software.com <mailto:info@capella-software.com>
Internet: www.capella-software.com <http://www.capella-software.com>
capella ist bei Facebook! <https://www.facebook.com/capella.Musiksoftware>

Registergericht: Amtsgericht Kassel, HRB 15433
Aufsichtsrat: Hans-Ulrich Werner (Vorsitzender)
Vorstand: Dr. Dominik Hörnel