Dear Matthew, dear david,
[EMAIL PROTECTED] writes:
> > 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 agree that you won't want to parse general mudela, but I do think that
> using mudela as your file format would be best. It seems to me that
I do not see how you can efficiently parse only a subset. Mudela is
made for *human entry*, not for simple automatic processing. It has
configurable note names, lots of identifiers, different lexer modes
etc.
If you want to give the most popular newbie functionality (1 staff
with notes, lyrics, chord names), you already have to parse three
different modes (lyrics, chord names which heavily rely on
identifiers, and notes). You also have to parse {} and <> (remember,
the melody might have chords in <> ) with its slightly hairy relative
mode semantics. I think offering decent functionality without also
parsing identifiers is difficult.
> Denemo is likely to serve pretty much as a `voice editor', meaning it
> will be used to edit the notes in one voice at a time. I think it would
> be nice to have it look in a mudela for special comments indicating that
> there is a voice to be edited, and then Denemo would only actually parse
> that voice, or rather those voices that are so marked.
Oh, but you wouldn't need markers for this. . . Just search for "\notes
{", and the matching "}"
> It seems to me that this would make Denemo relatively simple to
> implement and use, and yet allow it to still be a powerful tool for
> advanced mudela users who just have trouble reading 'a c b d a' and
> seeing music, but still want all the wonderful features that lilypond
> has.
I think that format to be used is completely besides the point of
denemo. Writing an interactive program is difficult, and music
notation is difficult, so a GUI notation editor is doubly so. I
suggest that work be started on the GUI editing core first.
I think that the best goal to strive for now, is to build a GUI editor
that can display and edit multiple simultaneous staffs of notes with
reasonable performance: that is the hardest part. Once you get that
working, the design of the data structures will give you a good idea
of what formats can and can not be used.
Secondly, if there is a working prototype, I'd perfectly happy to
provide an easier (from a programming p.o.v.) interface to lilypond,
so you won't have to worry about parsing hacks
I have another piece of advice. Despite the overall coolness and speed
factor of C and GTK+, I suggest to do the prototyping in a more high
level environment like Java or Python.
Using C will get you bogged down with chasing dangling pointers,
library version dependencies, memory management, unitialised data and
other various irrelevant details. We learned this the hard
way. Please learn this by the easy way, and don't start out with C (or
C++ for that matter). Your productivity is much higher with more
advanced tools.
I am very sorry that I tell you people so many things that you should
*not* do. I'd rather explain what *is* the best way to build a GUI
notation editor, and give positive feedback, but the sad truth is: I
don't know how to write such a beast, because I have never tried.
So this my only piece of positive advice: "Focus on the core of matter
and Try!"
Good luck.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
