Re: MNX proposal §1.2

@Joe: apologies for re-posting this, but it didn't arrive on 
public-music-notation-contrib@w3.org first time. My sender address was 
configured incorrectly.

Hi Joe,

> I realize that this note is unlikely to change your mind or your 
> direction, but I would like to briefly correct a few mistaken 
> impressions that I hope others do not take away.
I hope the others are not getting mistaken impressions! If anyone wants 
to join this discussion, they are very welcome! Thanks, Joe, for your reply!

>
>     The problem with MusicXML is that it was designed for sheet music,
>     and sheet music contains purely spatial information. Temporal info
>     is inferred from the graphics, but that is a mistake. Any temporal
>     info associated with sheet music is stored in living traditions of
>     performance practice, not on the page. Metronome marks are just a
>     way to transfer temporal info into a performer's memory.
>
>
> Sheet music in any well-known notational idiom (CWMN being just one) 
> is spatial information that refers to *a shared understanding* of the 
> living tradition of performance practice. As such, it is semantic 
> information: there are underlying concepts that we all recognize as 
> referred to by the same marks, regardless of their geometric details.
Can we agree then that "semantic information" is "/*a shared 
understanding* of how particular symbols, in a particular context, 
relate to a living tradition of performance practice/". Remember that 
performance practice for Wagner is not the same as for Mozart or Bach.

> Consider this analogous to the fact that the marks you are now reading 
> refer to *a shared understanding* of the living tradition of the 
> English language. Thus, we do not consider an ordinary, textual book 
> -- or an email, like this one -- to be "purely spatial information".
Right. But there is still a level at which it can be considered purely 
spatial information. This is very like the famous use-mention 
distinction in programming.

>
>     MNX describes computer files that are not restricted to spatial
>     information in this way. Spatial and temporal info can be stored
>     in the same file. So, when migrating MusicXML files, MNX has to be
>     explicit about the type of the information it is describing. Is it
>     spatial or temporal?
>
>
> You are leaving out the main dish: it is semantic, and not spatial or 
> temporal.
I don't see how a computer file could include the main dish. The 
semantics are located in the readers' minds, and computers have no 
access to minds. Nobody really knowns how and why brains interpret the 
world in terms of space and time. Performance practice traditions are an 
exclusively /human/ undertaking, and are what real music making is all 
about. Actually, I think real AI will only happen when somebody works 
out what space and time are to a brain, and how our memories work. 
That's going to take a few decades yet. Meanwhile computers should stick 
to dealing with well understood physical parameters: pixel-widths and 
milliseconds.

> All of the elements in MNX that you critique as being spatial -- 
> <tempo>, <event>, and so forth -- are semantic in nature. They encode 
> the *shared understanding* of the symbol. And this is only possible by 
> restricting the language to a specific universe of understandings;
No. Beethoven's tempo markings are often treated with a pinch of salt...
All I said was that <tempo>, <event> and <tuplet> have spatial 
dimensions that shouldn't be ignored. <event> also has a temporal 
dimension that (for computing purposes) can be measured in milliseconds.
I think you have to accept that all music notations contain 
/*annotations*/ that are addressed to human minds, and that have no 
exactly definable meaning in the perfect mechanical world populated by 
computers.
MusicXML, however, uses the "perfect mechanical world" paradigm, so you 
are quite free to use it when writing a program to transcribe the 
physical durations (milliseconds) of its symbols. That's what MusicXML 
means by its tempo, tuplets, duration classes etc. I see no problem there.

> in this case, CWMN. Without such a restriction, one may adopt a purely 
> spatial approach for encoding music, in which case SVG is a reasonable 
> vehicle. But that would fail to address many of our main use cases.
How so? I don't see how my approach would in any way restrict your 
object of creating a format that simplifies MusicXML. So it can't lead 
to a restriction on the number of use-cases covered.

> For this reason we've left room to encode purely graphical scores by 
> embedding them within MNX.
As I said, I think its a mistake to treat CMN differently from any other 
notation. Things get much simpler and more powerful if you dont.

> I believe there are multiple approaches to connecting SVG to MIDI (and 
> other audio formats) that may be better to the one that you've 
> proposed, and I am in the process of pulling in some other W3C folks 
> whose expertise is very relevant to this discussion. More on that soon.
That would be great! My experiments are working, but there may well be 
better ways of doing things. My Javascript is pedestrian, I don't use 
CSS enough, and my knowledge of XML is fairly superficial. We really 
need an SVG expert or two.
Synchronizing scores to other audio formats needs some thought. My own 
feeling is that that could be achieved via the temporal data I'm 
proposing, but the topic needs looking at with a much wider knowledge of 
the existing web standards.
>
>     What the symbol/means /is temporal information that should be
>     supplied separately.
>
>
> Actually, in MNX both the spatial and the temporal information are 
> supplied separately from semantic information. Please see:
>
> https://w3c.github.io/mnx/overview/#styling
> https://w3c.github.io/mnx/overview/#interpretation
>
Remember that you are proposing to write an application that converts 
MusicXML to MNX, and that MNX is an interchange format that can be 
converted, using some editor, to an instantiation (that I'm proposing 
should be some form of SVG+MIDI, because these are existing W3C standards).
I think we need to think about how and where, in this sequence, styling 
and interpretation info could/should go.

> In the interests of brevity, I will leave it here.
Ditto. There's a lot to discuss! :-)

Best,
James