Re: MusicXML

[Urs Liska]

Am Dienstag, den 23.04.2013, 21:43 +0300 schrieb address@hidden:
> On 23 avr. 2013, at 21:21, Christopher R. Maden <address@hidden> wrote:
> 
> > I am comfortable with LilyPond, but not quite an expert.
> > 
> > I am an expert in XML and XSLT, and it sounds like it would be of
> > benefit to LilyPond to have better support for MusicXML (though I don’t
> > use it myself).
> > 
> > Can someone please summarize (or point me to a summary of) the current
> > state of MusicXML support, what needs to be done, and the
> > infrastructure?  E.g., is a standalone XSLT conversion acceptable, or
> > should MusicXML import/export be integrated into the core LilyPond code?
> > 
> > ~Chris
> 
> There is currently a python script called musicxml2ly that will convert 
> musicxml to ly fairly reliably.
> 
> For the other direction, the only possibility at this time is to convert an 
> outputted MIDI file to MusicXML.
> 
> For me, it would be maybe 2 weeks of work to exhaustively convert what
> we call the "music stream" to MusicXML.  This could be faster or
> slower depending on how familiar one is with Scheme, LilyPond and XML.
> The "music stream" is the internal representation of the music in
> Scheme that gets passed to what we call "engravers" (Stem_engraver,
> Clef_engraver, etc.) from which graphical objects are made and then
> eventually split over systems if necessary.  To get more precise
> information about layout into the MusicXML would be difficult, as
> there is not a one-to-one correspondence between events in the music
> stream and musical objects created.

Is the information that eventually leads to the point-and-click links
present at that stage?
(I think it should because I couldn't imagine how it could be added
later).

Maybe this could be a bridge for a two-way approach (music stream and
input file parsing)?

Urs

> 
> Cheers,
> MS
> 
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user