Re: some Musikmesse and MusicXML

[Janek Warchoł]

Many thanks for this report!  You made me realize that i didn't
promote LilyPond actively enough.  We have unique features to offer
and people in the music industry should know about us.

cheers,
Janek

2013/4/22 Klaus Föhl <address@hidden>:
> 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
>
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user