Re: MusicXML backend for lilypond?

[Stuart Pullinger]

Reinhold Kainhofer wrote:
> Am Mittwoch, 18. Juni 2008 schrieb Han-Wen Nienhuys:
>   
> > On Wed, Jun 18, 2008 at 3:18 AM, Reinhold Kainhofer
> >
> > <address@hidden> wrote:
> >     
> > > Now that musicxml2ly has been noticed as doing quite a good job, I'm
> > > thinking of adding a MusicXML backend to lilypond, so that we can also
> > > produce MusicXML and export lilypond scores to e.g. Finale, etc.
> > >       
> > The last time we looked at this, I think the resolution was to dump a
> > music stream from LilyPond and postprocess that.  Read Erik's thesis
> > (available from the lilypond website) to gain some insight in the
> > design.
> >     
>
> Thanks for the hint, but unfortunately, the stream does only contain the 
> musical content in time-sorted order. MusicXML, however, also contains (or 
> rather, can contain) full information about page layout, breaks, object 
> positioning and similar settings (this has been extended a lot with MusicXML 
> 2.0). Since the stream is generated before the layouting stage, there won't 
> be any way to produce MusicXML files containing full page layout. In 
> musicxml2ly, of course, I simply ignore any layouting information present in 
> the file, because lilypond probably will do the job just as well ;-)
>
> Since Lilypond produces a layout that is far superior to any other notation 
> program (well, except for the vertical spacing of multi-staff 
> groups/systems....), of course, I'd also like to include that information in 
> the xml files... [1]
>
> Cheers,
> Reinhold
>
> [1] This is also my plan "B" for my orchestral scores: Currently it seems that 
> lilypond's page layout is not suited for full orchestral scores with choir 
> staves. If I can't implement proper vertical stretching (which produces 
> professional spacing/stretching with nested groups, staves with lyrics, 
> etc.), then my only way out is to switch to another notation program to 
> produce camera-ready scores...
>
>   
Forgive me if what I write here seems obvious. I have been looking at 
the SVG output of lilypond on and off for about a year so I hope this is 
relevant. Also, I'm using version 2.11.20 which may be a bit out of 
date. As I understand it, the problem is this:

- output to each file format is determined by scheme code in the scm/ 
directory of the source tree. e.g., for svg, the files are 
output-svg.scm and framework-svg.scm.

- the data structure that is passed between these files and some c 
functions contains the graphical objects for the visual rendering of the 
score.

- these objects are processed (ie. printed to the output file) in the 
order in which they appear in the data structure which no longer 
represents the musical ordering.

Problem: the data structure which is passed to the scheme functions 
above does not contain the music position - rather it contains the 
graphical information eg. font, X,Y position etc.

Problem: from my knowledge of MusicXML v1, I understand it requires 
notes to appear in musical order.

So, is it possible to carry information about the position of a note in 
the score through to the graphical rendering stage? Here's an example of 
a hack I have used:

To get bar number to be available in the NoteHead grob, add these two 
lines to lily/note-heads-engraver.cc in the process_music function:

SCM barnum = get_property ("currentBarNumber");
note->set_property ("barNumber", barnum);

Then you can retrieve the value, after the typesetting has taken place, 
in scheme:

(if (not (null? (ly:grob-property grob 'barNumber)))
   (object->string (ly:grob-property grob 'barNumber))
   "")

This doesn't solve the problem that the lilypond functions receive the 
data in a different order to that needed in MusicXML. I see 2 
possibilities to solve this issue:

1. The page data structure is preprocessed to order the objects into the 
order required in the MusicXML file. Then the structure is processed by 
the scheme functions similar to those used to output SVG.

or
2. The page data structure is passed to a separate function which 
creates a DOM tree, processes the objects in the order in which they 
appear but inserts them into the DOM tree in the order in which MusicXML 
requires them. I am not aware of any Guile/Scheme DOM implementations 
but this could be implemented in C using libxml (I think).

or
3. I suppose you could try to change the order in which grobs are added 
to the data structure which is passed to the output-*.scm functions but 
this sounds difficult to me.

I'd appreciate comments on this. I see the problems encountered in 
outputting MusicXML as similar to those I've encountered in adding 
metadata to SVG output.


Thanks for your time,
Stuart