Re: some Musikmesse and MusicXML

[Vaughan McAlley]

On 23 April 2013 02:01, Klaus Föhl <address@hidden> wrote:
>
> Hello,
>
> As Urs initiated quite some discussion with his 'lobbying' paper,
> I shall turn my ballpen-on-paper notes from Frankfurt into Bytes...
> ... my comments, clarifications {} ...
>
> organised by scorio { it took some locals to get that done }
> workshop (open to the public) entitled
>
> Beyond PDF - Exchange and Publish Scores with musicXML
>
> INTRO
> "PDF is a dead thing" { electronic paper}
> [there will be] new things we don't even yet envision
> start as exchange format between programs
> { Sibelius is mentioned- yes, "even supertankers can run aground" }
> { a case to safeguard work / investments }
> [currently] islands, not feeding all info into export]
> { example of MIDI export at one point }
> { keeping things to oneself - as some CAD programs do }
> [idea of] single-source publishing {as ambition}
> { referring to earlier discussion, output devices very variable,
>   even beyond A4 vs letter}
>
> Michael Good - *digital sheet music* [musicXML] in Recordare in 2000
> { showing some slides to give an introduction }
> available under an open, royalty-free licence
> that is friendly to both open-source and proprietary software
> PDF - wonderful paper substitute, but no reflow etc.
> musicXML notation format, semantic elements - both look and have play-back
> { giving some rather specific graphical specification, staff line sep as unit 
> }
> i.e. separation between key, harmonics, signature and note, alteration
> { adressing both semantics and visual display }
> archival format, backward compatibility { emphasis on that }
> for the far future standard organisation / like PDF
> no DRM controls built in , have been added in Open Score Format
> more Vendor-to-Vendor than Vendor-to-User format
> Question: what about tidying up format?
> Answer: selective encoding, not everyone required to encode all aspects
> [showing software importing/exporting musicXML]
> even to SDK applications  OSF (Open Score Format)  *Book: XML in Music
> telling about improvements in documentation
> { MG having to } Finale doc to finisch before XML docu going on
> { so far there are } de and ja translations { web site ? }
>
> ** round of introduction, taking names and affiliation/interest **
> Now comes the discussion, wishing for features etc.
>
> Question/Comment: turkish/persian accidentials
> rational, non 12semitones-subdivision - how to indicate 3rd or 7th tone
> { functional position as opposed to frequency pitch }
> aleatoric passage   ref. Daniel Breadbury {???}
> fret numbering in roman numerals
> multimetric notation
> standardisation of musicology notation
> Answer MG {to what?}: do not want to add features in absence of implementation
> verse numbering - not being part of text
> [record manually fixed] stem direction
> up/down by rules, but record user flip { my thought: what in transpositions }
> experience of publisher, taking 12-15 per page to remove bar numbers,
> [based on] XML as provided i.e. by Musicalion
> { my thought: sounds like "graphical programming instead of structured
>   programming } { graphical level of info }
> { some user reports on needing some dirty graphical tricks in old times, old
>   music notation software (breaking music) to reach desired print look }
> Question: critical editions - original vs editorial additions
> Answer: extensive workshops on that in the past
> Request: mapping slur (programmed as font) to map to semantics,
> i.e. [there exist] versions of handle fonts {fixed gr. vs mor flexible grobs}
> Answer: grouping element could cover that { -> no necessity for new stuff }
> font element to XML mapper  Comment: exporter responsibility
> positioning of :|| and such, which edge of thick bar line [ is taken as
> the reference position ] (more accidentials destroying text alignments)
> alternative origin?
> Answer: x-origin currently unspecified { sounds a wee bit like pixel-schubsen 
> }
> Comment: lots of digital music has been created for music print
> (not necessarily for music playback, semantics), lots of graphical fixes
> Question MG: does one need spec, or is email list sufficient?
> Comment: [for that person being on 1+ standard boards musicXML is the]
> only standard without a proper documentation
> presentation of overarching ideas as a whole [desired]
> dtd does not expose the general principle
> draft version and source version control
> semantics / graphical info  sort into different roles
> [concrete problem] fingerings exported as text, non-recoverable after export
> developer-focussed docu, not so much for engravers and publishers
> Comment: get music out of MIDI, now turing towards XML
> what is important, what can be supported economically
> {essential parts} core features vs optional features
> remark: unofficial test suite from Lilypond
> question/desire: tool for correcting musicXML including graphical
> representation of the logical structure, usable for non-experts
> comment: bug tracking as complimentary { is there in other standards }
> public bug tracking list
>
> closing: statement: standard for digital music publishing
>
> So far my transcription - maybe some food for thoughts
> as we in Lilypond are not that far away from musicXML
>
> Klaus
>

Interesting... thinking about all this, I think the future of music
notation will be on e-readers, sacrificing beauty and quality for
convenience. Sadly, e-books and the MP3 format have shown that people
will happily do this, making printed book-lovers and audiophiles a
niche market. This will probably happen for printed music once the
technical issues are overcome. Music reflow (or something like
Finale’s Scroll View) will be an absolutely crucial part of all this.
Unfortunately, this will negate one of the things I like most about
Lilypond—its page layout.

Once there is a music equivalent of the MOBI or ePub format, perhaps
Lilypond should work at making e-music files that look good on
whatever the standard reader is. I’ve experienced a wide difference in
quality between e-books on my Kindle, and e-music should be no
different.

(As an aside, I’ve lately been learning Tex by publishing my mother’s
autobiography. The book should look great. If I want to create a
version for e-readers, it looks like I have to get to ePub via HTML
format. It seems a shame, because the Tex source probably contains all
the information one would need to produce a nice e-book)

Vaughan