Re: some Musikmesse and MusicXML

[Klaus Föhl]

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