[EMAIL PROTECTED] writes:
> Han-Wen> this is put into the document. If we can keep this thing
> Han-Wen> alive for half a year, we probably have gathered enough
> Han-Wen> material for good documentation. In the same time, I can
> Han-Wen> try to be your mentor in explaining LilyPond. But *you*
> Han-Wen> must ask the questions.
>
> Yeah, I would be willing to take this on.
OK, I'll assume that you will be in charge of the contents of
internals.yo. You may change the contents the format whatever you
like. Just send me the diffs.
I just corrected some minor issues. Diff attached.
I'll also go through my outgoing mail, to see if there are any
interesting documents. I'll send them by private mail.
> Let's start with figuring
> out what you feel is working well, and is unlikely to go through any
> major overhauls. This makes sense, because it would be silly do all
> the work on stuff that is going to change drastically in the next
> version. (Of course, in the process of documentation we may very well
> discover something that should be changed. This is a good thing.)
>
> For instance, the basic scheme of Requests, Engravers, and the stuff
> described in the current internals.doc seems to work well, and has
> been working for quite some time.
I think that the rough syntax of Music is OK. The way Engravers and
Iterators work is also OK. The back end is the thing that needs most
overhauling.
> Basic notes on the staff, barlines,
> and clefs there for a year now, and we might consider the mechanism
> stable?
Which mechanism exactly? Clefs, notes and barlines are all derived of
Item, Score_element and Graphical_element. All of these have seen
major revisions over the past year.
--
Han-Wen Nienhuys, [EMAIL PROTECTED] ** GNU LilyPond - The Music Typesetter
http://www.cs.uu.nl/people/hanwen/lilypond/index.html
--- internals.yo~ Tue Sep 15 19:22:43 1998
+++ internals.yo Tue Apr 13 11:36:41 1999
@@ -25,27 +25,28 @@
dit(Interpreting music)
-The music is walked column by column. The iterators which do the
-walking report the Request to Translators which use this information
-to create elements, either MIDI or "visual" elements. The translators
+The music is walked through in time-order. The iterators which do the
+walking report Music to Translators which use this information to
+create elements, either MIDI or "visual" elements. The translators
form a hierarchy; the ones for paper output are Engravers, for MIDI
Performers.
-The translators swallow requests, create elements, broadcast them to
-other translators on higher or same level in the hierarchy:
+The translators swallow Music (mostly atomic gobs called Requests),
+create elements, broadcast them to other translators on higher or same
+level in the hierarchy:
The stem of a voice A is broadcast to the staff which contains A, but
-not to the noteheads of A, and not to the stems, beams and noteheads
-of a different voice (say B) or a different staff. The stem and
-noteheads of A are coupled, because the the Notehead_engraver
-broadcasts its heads, and the Stem catches these.
+not to the stems, beams and noteheads of a different voice (say B) or
+a different staff. The stem and noteheads of A are coupled, because
+the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
+these.
The engraver which agrees to handle a request decides whether to to
honor the request, ignore it, or merge it with other requests. Merging
of requests is preferably done with other requests done by members of
the same voicegroups (beams, brackets, stems). In this way you can put
the voices of 2 instruments in a conductor's score so they make chords
-(the Stem_reqs of both instruments will be merged).
+(the Beam requests of both instruments will be merged).
dit(Prebreaking)
