Re: The MusicXML Technical Requirements document

Hi Joe, all,

> Thanks for posting here -- I will put some kind of notice in the 
> "Talk" sections to avoid this kind of confusion in the future.
When I've finished replying to this thread, I'll look and see if my 
"Talk" response is still relevant. If so, I'll move it to a new thread 
on this list.

> The Technical Requirements have simply been moved from their old 
> location and are actively being revised. I completely agree that the 
> original content labeled "Arbitrary apps working with notation" was 
> not very useful or well conceived. It's already been partly reworked 
> by transforming it into more specific user stories (now labeled as 
> WEB1-WEB6 on the Use Cases page).
Actually DEV1-DEV6.

>     We can/should distinguish between web and off-line (i.e. desktop)
>     applications.
>     Developers have to decide which kind of app they are developing,
>     and then choose the appropriate tools (languages and
>     technologies). Its a very good idea for offline (desktop)
>     applications to support MusicXML, but Javascript+SVG is the name
>     of the game on the web. Browsers are never going to support
>     MusicXML natively, but SVG already displays correctly "out of the
>     box".  An important distinction between these two types of
>     application is that desktop applications have to be installed,
>     while web apps dont. Also, web apps are (currently) always
>     open-source -- which affects the (financial) context in which they
>     are written.
>
>
> I agree that we should distinguish these cases. However I believe that 
> the offline/online distinction does not really dictate a choice of 
> which standards to use in which environments.
>
> MusicXML (or something like it) aims to be a standard that encodes 
> notation, not an image of what notation looks like -- I'm sure we 
> agree on that. That in itself tells us when to use it, vs. when to use 
> SVG. The fact that browsers are not going to support it natively, 
> doesn't affect MusicXML's relevance to the Web, or make it a 
> "native-oriented" technology.
>
> For example, MathML is a W3C standard and a web technology for math 
> formula markup, but it is generally not supported by browsers (and 
> probably won't be): you need Javascript to render it. But it's been 
> widely adopted to show math formulas in web pages, across the board. 
> MusicXML is a lot like MathML: it can be used in any web browser, 
> given an appropriate software library that can translate it on the fly 
> into a browser-supported format.
Ah, I see what you mean. Writing a MusicXML renderer in Javascript 
sounds like a great idea... -- but I'm not going to give up easily! :-)
Consider the pros and cons (Maybe there are others?) :
Pro:
1. The Javascript could take account of the size of the user's device, 
so as to generate an appropriate display.
Con:
1. We are locked in to CMN1900 plus a few extensions.
2. All the low level, code that relates to font metrics in the 
MusicXML-compatible authoring software would have to be duplicated in 
Javascript. That's an enormous investment to have to make when a simpler 
(and more powerful) alternative solution is available.
3. Not so important, but worth mentioning, is that loading large fonts 
and scripts takes time. On the web, one should, ideally, keep file sizes 
(and processing time) down. Offline, that's much less critical.

Actually, I think that taking account of the size of the user's device 
is not as important as one might think. It would be very easy for 
authoring software to export SVG for various screen sizes, and for a 
script to choose the right file to load. Browsers also support 
magnification out-of-the-box.

Non-Standard music notations: CMN1900 is the most complicated/powerful 
notation system the world has ever produced. (Michael probably remembers 
that I made a Survey of the World's Music Notations for a MPEG4 
standardization effort in 2004.)
It must be possible for simpler, cheaper, specialised authoring tools to 
be created for simpler notations. Users should not have to buy 
Sibelius/Finale if all they want to do is write monophonic text 
annotated by neumes of some kind. Such simple software should not be 
obliged to export MusicXML -- though it could, if the developers thought 
it worth doing..
In my own case (putting my composer's hat on), I happen to believe that 
the invention of tuplets was a 19th century mistake, and have no desire 
to spend my time fighting obsolete ideas. So I dont want to use 
authoring software (or file standards) designed around tuplets, tempo 
and "divisions".

There is an abstract hierarchy of containers that can be used for any 
music notation that has ever been invented. This hierarchy has to do 
with chunking in human perception, and is easy to recreate using classed 
groups in SVG. The hierarchy goes like this:
Score->Page->System->Staff->Voice->DurationSymbol.
The top five containers are purely graphical, but DurationSymbols 
contain (separate) graphical and temporal information. SVG does not 
support such temporal information natively, but writing it in a 
specialised namespace is quite straightforward (especially if there's a 
standard that tells you how to do it).
Each container contains one or more sub-containers, but there are no 
restrictions on how they look or are arranged in space. Time can flow 
left->right, top->bottom or round in circles if one really wants that. 
(Dennis Bathory-Kitz might!) The arrangement of the containers on the 
page is only restricted by the authoring software.
If there were such a standard way to write SVG for web-based 
performance, then it would be possible for Javscript libraries to be 
created that would encapsulate things like user interaction with the 
GUI. And that would simplify the creation of performance software -- not 
only for non-CMN1900 notations, but also for CMN1900.

> If you want to move away from semantic representation, then your 
> approach makes perfect sense. SVG is a great graphical standard. But 
> while SVG can be annotated with some semantic information, that 
> doesn't make it easy to work with if you are concerned with the 
> semantics. Imagine transposing an SVG score into a different key, or 
> programmatically generating a melody. These are real use cases that do 
> not need any graphical information, and where it's either irrelevant 
> or it gets in the way.
Since the graphics and temporal information are separate in my proposal, 
its very easy to play the score in a different key than written, or at a 
different speed, or with different articulations. Its also very easy to 
synchronize the score with one or more external audio files of real 
performances. Durations can be changed on the fly by the app.
The graphics can also be changed dynamically by the app, but it would be 
better for dedicated authoring software to make larger changes (like 
transposing a whole score). That's a lot like the situation re screen 
sizes, where the authoring software exports different versions of the 
score, and the web app decides which file to load.

> I suppose that I believe semantic representation of music is at the 
> core of what this group, and MusicXML, is all about.
I agree that the semantic representation of music is what MusicXML is 
all about. And I think its a very good idea to try to finalize that 
standard. But I don't think that this group should restrict itself just 
to doing that. I think we should also be working towards a simpler 
standard that promotes the creative development of music notation.

Enough for now! :-)

All the best,
James

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