A NEW APPROACH

In the original design (the text is below, 
starting at SIMPLICITY OF FEATURES) the
intention was to support limited re-import of lilypond files.
With this version of denemo, a route to fairly general import
of lilypond files is being trialled. As Matt pointed out, you
cannot support everything in lilypond without writing an interactive
version of lilypond (complete with scheme interpreter, tex etc done on
the fly). But we don't need that. What we need is to visualize the
notes as we put them in and edit them - there are a lot of them and it
is difficult for musicians to "read" music that is just written as text.
But we still want to return to editing after adding lily directives - we
want to be able to interpret more or less any lilypond file so that we
can play with putting voices on a stave, adding fingerings to some favorite
score produced by someone else etc.
To support this, the lilypond lexer/parser has been migrated to generate the
denemo scoreinfo structure, while keeping the original text of the file with
the notes that may be edited. In addition to denemo's graphical window a 
text is opened to allow direct editing of the lilypond text. At present there
is no incremental parser, but in practice reloading the whole file seems
adequate (it would be nice to return to the same object after reload, though,
insofaras this has a meaning).
This design works broadly as follows. The parse tree generated is a list
except where assignments are made, where the thing assigned to is a branch
off the list. The items in the list are a generalization of the mudelaitem
structure, which has been expanded to include a field giving the string from
the input file that gave rise to the item.
After creating this list, it is traversed: the \context statements give
rise to the creation of new denemo "staff" structures and any music lists
found within the context are split into measures at the '|'s and attached
to the "staff" structure.
The original parse tree remains valid however - what was a single list of
musical items becomes a branch to a list of measures containing the original
pieces of musical item list. This means it is still possible to traverse the
tree and write out the original text.This is what is done when the file is 
saved - there is no re-interpretation of the notes which have not been changed
- the original text is just writen out again. When a new musical item is inserted, it
has no string associated and a standardized lilypond syntax is generated for
that item (using the routines of the old exportmudela code, which remains in
use for music written from scratch or imported from elsewhere).
Many benefits flow from this approach - to give just one example you can
define a key in one place and then use it in several - see examples/simple.ly
To change the key you just edit the one definition. There follows a corresponding
limitations. For example, it no longer makes sense to introduce another 
staff in the staff list of the score - where in the lilypond file should 
the definition go? - what should it be called? Sure, you could cope with all 
this graphically, but (unlike the notes) this is just one-off stuff better 
done by cutting and pasting a staff definition textually. 
So the basic design decision is that everything at the staff level and above 
is just used by denemo to let you get at the mudelaobjects, while
the mudelaobjects are actually *in* the original parse tree and will be output
when that is traversed. Without a clear cut division like this you would be left
with a mess when it came to writing the file out - which bits of the scoreinfo 
structure came from the original file and which have been added, and so on.
There are some wrinkles arising from grafting a new design on in this way.
Barlines are implicit in denemo - in the present implementation the textual
barlines can easily get notes inserted after them, they perhaps would be better
explicitly represented and given widths etc like other items. The '~' sign for
a tie does not come attached to its note in the lilypond parse, while in denemo
it is an attribute of the note before it. The handling of context (current
duration, and once we allow \relative music, current octave) is tricky, duration
is handled ok except at measure boundaries where you have to do it by hand.
Finally, there is a lot of the parser that hasn't had any rules written for it
yet, so don't expect any old lilypond file to get through it yet.


SIMPLICITY OF FEATURES

You'll notice that denemo doesn't have hooks for many of Lilypond's
features. (In fact, providing hooks for all of them would be
practically impossible without writing something at least as
complicated as Lilypond itself.) So, to use these specific Lilypond
features, the user will have to go into the mudela files denemo
produces and alter them directly, without denemo as a go-between.

Why is the user forced to do these things manually? Well, mainly, it
just doesn't seem that there's much advantage to a GUI environment for
putting playing directions directly into the music, fine-tuning the
way the music is beamed, putting multiple independent voices onto the
same staff, adjusting a staff's relative position, and other things
like that. In fact, it seems that there's a distinct disadvantage to
GUIfying these operations: pushing such features to the frontend will
burden the interface and make GUI tool harder to use. (I can say from
personal experience that this has definitely happened to Finale.) It's
just much better to handle this kind of complexity with the precision
and well-defined-ness of plain ASCII text.

I will admit that this manner of doing things will present challenges
to novice users. Users should find the effort to be worthwhile,
though. And it's not really _that_ difficult to learn how to use GNU
lilypond; it's still easier than, say, learning C plus its gtk+
bindings. :)


THOUGHTS ON THE RE-IMPORTATION OF MUDELA AND HOW DENEMO WILL SUPPORT IT

I want users to be able to use Denemo in two ways:

1) Denemo is used for the initial phases of score creation only. Later
changes in the work are made directly to the mudela that Denemo has
produced and no longer with Denemo. This work can involve drastic
changes to the mudela or more simple changes.

2) Both Denemo and direct mudela editing are used throughout the whole
process of score creation; the first editing session is done with
Denemo, but thereafter, Denemo sessions can alternate with
direct-mudela-editing sessions.

This latter way of using Denemo is best enabled (at least that I've
thought of) by giving Denemo the ability to reload exported mudela and
re-export it without losing any information. If a user wants to, I
can't stop them from making radical changes to the mudela that Denemo
produces that would prevent Denemo from re-exporting successfully. I
do want it to handle moderate changes gracefully, though, especially
when the user specifically designates a new block of mudela that
should be maintained as-is.

This is what the lilydirective data type in datastructures.h is
for. When Denemo loads mudela, any items which are specifically
designated as non-intelligible to Denemo will be retained as
lilydirectives and then written out again when the file is
saved. (Users will also have to be able to add, remove, and edit
lilydirectives within Denemo; otherwise Denemo would not be able to
deal with the deletion of a section of music containing Lilydirectives
on its edges sanely.)

Lilypond itself will not, however, treat mudela designated as a
lilydirective any differently. How? Lilydirective denemo will be put
on its own line, and it will have a different amount/kind of
whitespace in front of it.

The mudela parser works now - expect to see this in a release fairly
soon.