[EMAIL PROTECTED] writes:
>
> Anyway, the fact that Denemo isn't aiming to shield the user from
> mudela leads me to think it might be _better_ to use mudela as the GUI's
> native file format than if it did have that aim. It would allow music
> entry to alternate between GUI-editing and hand-editing. Otherwise,
> users'll have to throw out hand-edits if they want to edit their piece in
> the GUI again.
Please do *not* use Mudela as the format for your editor. The
lilypond parsing front end is about 4000 lines of code, and it is
complicated. (not counting identifier stuff, the data structures that
have to be read. If I would it would probably 6 or 7000 lines). To
try reading mudela would imply writing a second parser for mudela, a
complete waste of time, if you ask me.
I suggest you should brew your own internal format. The program should
allow the user to add arbitrary strings to the mudela output, so you
can get all the flexibility you need. If you do that you don't have to
constrain the design of your program with our idea of how to represent
music, and you don't loose time with trying to parse mudela.(*)
I think that this is quickest way to a working, useful program. And
remember, a working, useful program is quickest way to attract new
users and new hackers.
(*) This doesn't mean that I think mudela is a bad format, on the
contrary. But I think a GUI editor that only offers a subset of
LilyPond 's features could very well need a different format to read
and write files.
For instance: I could imagine that you would only allow one voice per
staff in denemo, so you don't have to worry about collisions, cross
staff switching, etc. Denemo writes the voices out as a mudela
include file, and the user builds a custom \score block to typeset the
music with lilypond.
In this case the format for denemo can be quite simple: a list of
voices, and each voice is a list of chords.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
