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.