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 <[email protected]>: > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
