Input parser

[Han-Wen]

address@hidden writes:
> 
> I am interested in working on importing Lilypond files into a 
> sequencer/graphical notation editor.  The task is somewhat daunting : )
> 
> In the opinions of experts, is this possible within reasonable 
> expectations?  Is there a recommended mode of attack, i.e. somehow reuse 
> the lilypond parser vs. attempt to maintain a "parallel" codebase?  (How 
> closely tied to output is the input processor?)  Or is it complicated 
> enough that lilypond->MIDI->Import is the recommended path?
> 
> A related question is if anyone could give an estimation as to how much 
> of the complexity is display-specific notation (vs. simply encoding 
> notes and their characteristics).  This application does not 
> particularly depend on pretty-printing, so is it possible to discard any 
> meaningfully-large parts of the syntax in hopes of easier coding?
> 
> I have written a very simple C++ parser as an exercise, but as with most 
> things, the first step is significantly easier than the "usual case".

I would say that it is fairly impossible. (And yes, I know this is
about RoseGarden, I lurk on the ML :-). The input to lilypond is very
high-level, and I doubt that RoseGarden format supports such niceties
as synchronized grace notes, automatic part combining, or semantic
repeats (i.e.

   \repeat "volta" 5 { .. } \alternative { .. }
   \repeat "tremolo" 4 { .. }

). Parsing Lilypond input would only get you big a tree of music
expressions.  Getting that into something that RoseGarden accepts
would be difficult without duplicating the hairiest parts of LilyPond
(music iteration, i.e. synchronization of events.)

That being said, the nice part is that there is simply no display
information in the input, so you don't have to worry about that.  I
see three possible routes:

 1. Write all code (parsing, synchronization etc)
    yourself. Difficulty: depends on thorough you want to be. The hard
    part of this is that lilypond includes embedded Scheme as a
    feature, so you can do nifty stuff like

    \apply #(lambda (x) (reverse-music x)) \notes  {  .... }

    parsing that is so much work, that option 2 would be a lot easier.

 2. The smarter route:

    Notice the \apply function above? You can simply dump the entire
    input file as a Scheme expression:

    \score { 
      \apply #display  \notes { ... }
    }
    
    shows you the complete parse tree for the music, and if you want I
    can add some hooks, so that you can get the \paper {} block as
    well. No parsing code needed, and if you want to dump in XML,
    simply write some Scheme code that does a conversion.

    Problem that remains, is that you will have to synchronize music
    expressions, i.e. putting the D and the G above each other in 

    { c4 c2 c4
      < { c8 c8 d8 
          g4    g16 a16 } >
    }

    As explained things get hairy when grace notes and repeats enter
    the picture

 3. The coolest option:

    Write a new backend for LilyPond. Currently, we have 2 (one for
    notation, one for MIDI). It would be mighty cool (and very
    convenient for people that want to export LilyPond to whatever
    format) if we could have a 3rd one; one that dumps some kind
    synchronized music events (for example, in XML). I think that in
    the long run this is much easier to do than both 2. and 3, because
    it involves much less hairy code than 2. and 3.  The XML backend
    would be simpler than MIDI (which is already way more simple than
    the notation backend).

    The caveats are that the bulk of the work will be done in
    LilyPond, not in RoseGarden, but I'm not sure if you would mind.
        

Oh, I forgot a fourth one: rip apart the lily source code, trying to
see if you can force it into RG. I think that it is an unpractical
idea, because you will have to import enormous amount of overhead
(.scm, .ly files, various C++ support stuff, GUILE linkage) to get it
working.





--
Han-Wen Nienhuys   |   address@hidden   |   http://www.cs.uu.nl/~hanwen