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

James, 

I think you're missing the point. 

You seem to distinguish only two types of applications:
* editors (Capella, Dorico, Sibelius, finale, museScore)
* programs that play back music

And from where I stand (and quite some others here), that's exactly *not* the main use case for MNX. 
* music editors typically don't care that much for interchange between each other. You don't want to encourage people migrating to the competition, do you? (That's also why MusicXML import is typically better implemented than MusicXML export...). So MNX isn't really needed for only that purpose.
* programs that play music can just use MIDI for playback - we don’t need another standard to cover that. It's quite easy to couple progress of a PDF or SVG based score to a temporal progress. There's very limited metadata needed for that, and that's hardly a motivator for a standard. 

What do I see as the target for MNX? It's a range of applications in between that typically could be broadly categorized as "digital sheet music viewers/manipulators". They are applications that provide an on-screen experience that surpasses the mere paper representation. 

These would allow to
* transpose to accommodate other instruments, 
* allow to see other people's parts so you can better play together or see some notes you have to play in someone else absence
* reformat the score to fit the size/orientation of the screen you're using
* reformat the score to fit your preferences (size, key, clef, style ("font"), ... )
* interchange annotations (while reflowing the score to make room for such annotations)
* etc... 

Such sheet music viewers also don’t care much about playback. The main goal is to let musicians play themselves. 

All of these innovative use cases cannot be covered by an SVG+MIDI standard. And most of them have difficulty with limitations of MusicXML (most notably the lack of a "system" concept and the lack of real tuplets, both of which are covered by MNX - yai!). 

The SVG extension in MNX is merely there to be able to cover specific graphics you sometimes see that don’t fall within the normal CWMN conventions. It's certainly not there as the "main use case". 

You can actually see in the way that Joe is proposing MNX that this range of applications is the real target. There are provisions there that make parsing simpler, and that make dynamic rendering simpler. That all fits well with the use case of dynamic sheet music viewers that don’t have an 8-core i7 to re-render the sheet music (read Daniel's blog on how they optimized Dorico to take advantage of the full power of such processors to reach their goals). 

I have to say that I'm actually quite pleased with the first draft of MNX as it was presented. If we go along that route, then my life will become simpler. Unfortunately it's going to take some years before we see MNX being defined and actually supported, so I'm not holding my breath. 

All the best, 

JanR


> -----Original Message-----
> From: James Ingram [mailto:j.ingram@netcologne.de]
> Sent: vrijdag 31 maart 2017 14:17
> To: Jan Rosseel <jan@scora.net>; 'Rafael López García'
> <phy.development@gmail.com>; 'Joe Berkovitz' <joe@noteflight.com>; 'Dr
> Dominik Hörnel' <d.hoernel@capella-software.com>
> Cc: public-music-notation-contrib@w3.org
> Subject: Re: MNX Proposal now Available [via Music Notation Community
> Group]
> 
> Hi Jan,
> 
> >> Remember that MusicXML is primarily a graphics standard, designed for
> sheet music.
> > Well, not exactly.
> I'm afraid we'll have to agree to disagree about that.
> >> The first pass defining MNX should define it purely as a graphics standard,
> ignoring any (temporal) meanings.
> > No. Make that "Hell No". The lack of some key semantic elements in
> MusicXML, and from there its utter lack of enforcing programs to dump
> semantically correct CWMN, is its main deficiency.
> MNX is expressly designed to correct MusicXML's deficiencies. I'm sure it will
> be an improvement.
> > Degrading MNX to a pure "spatial" standard completely defeats [the]
> purpose.
> This is a misunderstanding: I don't think MNX should be a purely "spatial"
> standard.
> 
> > I think it's fair to state that the majority of people interested in MNX are
> interested in the ability to create applications around MNX file.
> As I understand it, MNX is intended to be an interchange format that can be
> shared by score editors (Dorico, capella etc.). Such applications already
> export SVG instantiations of the scores. (I think they will in future also be
> able to export SVG+MIDI instantiations.)
> 
> In the "Graphical scores and SVG" thread, Joe's option #2 was:
> > Joe:
> > 2. SVG (with some relationship to sound) can serve as an intermediate
> > format that represents *a specific rendering* of semantic music
> > notation markup such as MNX, MusicXML, MEI, or anything else.
> about which he said:
> > Joe:
> > [...] Consider that [SVG+MIDI] permits semantic markup to be converted
> > into a format that can be easily displayed and played back by an
> > application that is much simpler than one that processes semantic markup.
> Given that score editing applications are large and complicated compared
> with the applications that will be able to use SVG+MIDI, I think there may
> well be even more scope for application development around SVG+MIDI than
> around MNX.
> 
> Joe continued:
> > Of course, [SVG] is necessarily quite limited in other ways (try
> > transposing it to another key, or reformatting it for a different
> > display size!)
> Note that there's an interesting difference between graphical and temporal
> info in SVG+MIDI files: While Joe is right that transposing the graphics or
> reformatting the score is practically impossible when its in the form of
> instantiated SVG, the same is not true for the temporal info.
> An SVG+MIDI client application can quite easily change the temporal data
> before using it. For example, without changing the graphics, it can change
> the playback speed, performed pitches, volume, timbres etc... And still
> remain synchronous with the graphics. It could also select between
> completely different, real, embedded recordings.
> 
> Just saying...
> 
> All the best,
> James
> 

Received on Friday, 31 March 2017 13:24:24 UTC