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

Hi Rafael, Joe, all,

Rafael said (about his speciality, Okinawan notation):

> But I understand that this tiny and infrequent use case, as medieval 
> music notation, will be out of the scope of your standard.
I think that both Asian notations and mediaeval European notations 
should be in scope. They are in the use cases.

@Rafael: As I understand it, Okinawan notation reads from top to bottom, 
with the columns being read from right to left. This is essentially a 
simple rotation of 90 degrees from the way CMN is read. In fact, 
depending on how MNX decides to organise its container hierarchies, and 
whether or not you use measures, you could consider each column to be a 
<measure>, <staff> or <system>. I don't see any problem there.

I think there is going to have to be some mechanism in MNX to specify 
the type of the notation being encoded. It would therefore help the 
group to know more about the variability within Asian notations. I'm 
going to open two new threads where we can talk about that:
1. Asian notations: The directions in which they are read
2. Asian event symbols

@everyone: Please reply, if at all, to one of the above threads (not 
this one).

All the best,
James


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

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