some Musikmesse and MusicXML

[Klaus Föhl]

Dear all,

Earlier this month I was at Musikmesse.
As I had some time to spare (a music sheet house was absent)
I attended a scorio-sponsored/organised workshop on MusicXML.

I declared myself as an [evening] choir conductor and LP user.

After a few introductions Michael Good was collecting 
suggestions on what details need to be added to MusicXML.
One aim as mentioned was to bring publishers and developers
(and a 3rd group, users/composers/musicians) together.
One declared aim was to establish MusicXML as an exchange format.
But then during discussions it was admitted that publishers might
want not to deliver MusicXML to the end user but something protected,
so more of a vendor-to-vendor format.

Music reflow (to adapt display for different tablet sizes
and geometries) was mentioned multiple times. Also transposition
was raised, to my feeling a big thing was made about it.
MIDI does not preserve formatting information, PDF is "paper" only.

Michael Good emphasised that MusicXML 3.0 and 1.0 are backwards
compatible, and future versions should maintain this compatibility
to allow the use as an archive format. UTF-8 also helps.
Features should only be removed/tidied up if positively 
not a single person has used any such feature in the past.

There was more talk about what is necessary for standard definition,
and achieving comparable output on different rendering engines.

Possibly there are minutes on the MusicXML email list. I do not know.
And the few lines above are by far not a complete writeup.
Now some impressions from that workshop but also more general from the fair.

Music display on tablets and e-readers starts to be promoted.
My gut feeling, comparing digital camera use in 2001 and 2008,
is that we are at the beginning of a major shift.

One question is how many of the easily achievable additional
benefits will be handed down to the end user. Display reflow
and transposition? Two staff piano reduction from 4 staff part songs
(me the part time choir conductor), music playing along moving music,
or (first examples on display) music sheets following your playing.

Big publishing houses are still mostly paper only towards the end user.

What I noted on the scorio displays: some staff lines were one pixel
wide solid back, some two grey pixels wide. I have an idea how and
why this is due to the workflow (I have turned PS or PDF into 
low-res PNG in the past as well) but there is some room to do better.

Back to MusicXML. Some of the problems discussed were down
to graphics-driven notation (fine on paper) i.e. bar numbers
coded as plain text, so they could not be retrieved at a later stage.
Also I was wondering about precise/rigid geometrical descriptions
(that are feasible) which might get in the way of reflowing music
where logical structure encoding might be more appropriate.

Archive format is something which I would love to see.
MusicXML has the ambition to be one, but certainly is not
meant to be efficiently human-writable because of all the markup.
Lilypond syntax is not declared stable but has the advantage
that it is rather concise, and music typed on computer keyboard
is a rather efficient process.
(N.B. Plaine & Easie Code is even more condensed than Lilypond code)

Where do I see Lilypond. Not only as the rendering engine it is
(as was mentioned in that Musikmesse workshop), not only as a
reasonably well documented description language. While interfacing
to whatever standard is in place (currently MusicXML) helps to
make it acceptable for integration into workflows that do not
lock someone it, I personally see a significant component 
in the syntax that is condensed (good typing) and readable,
hence using Lilypond syntax for actually entering music content.

Best regards

Klaus

P.S. maybe (on sufficient demand) I turn my paper notes into Bytes...