lilypond-0.0.33

diff --git a/Documentation/lilygut.pod b/Documentation/lilygut.pod
index e348b644d0f914ff114fac7c440dabf8b107b86f..1ac0c5290d31ae837e68f566d9dc6fcbedbc5e47 100644 (file)
--- a/Documentation/lilygut.pod
+++ b/Documentation/lilygut.pod
@@ -25,8 +25,10 @@ No difficult algorithms. Associated datastructures have prefix Input
 
 =item 2. Processing:
 
-Requests are processed and granted. In this step data-structures for
-3. are created and filled with data: PScore, PCol, PStaff
+Requests are processed and granted. This is done by three cooperating
+structeres: Staff, Staff_walker and Staff_column.  In this step
+data-structures for 3. are created and filled with data: PScore, PCol,
+PStaff
 
 =item 3. Calculation:
 
@@ -140,11 +142,11 @@ should not be shared.
 
 The judge in this "allocation" problem is Staff (actually, it's child
 C<Complex_staff>). It uses the C<Request_register> to do most of the
-work class.  For each request C<Complex_staff> queries so-called
+work.  For each request C<Complex_staff> queries so-called
 C<Request_register>s if they want to accept a request eg, the
 C<Notehead_register> will accept C<Note_req>s, and turn down
-C<Slur_req>s. If C<Complex_staff> cannot find a register wants the
-request, it is junked (with a warning message).
+C<Slur_req>s. If C<Complex_staff> cannot find a register that wants
+the request, it is junked (with a warning message).
 
 After all requests have been either assigned, or junked, the Register
 will process the requests (which usually means creating an C<Item> or

diff --git a/Documentation/lilyinput.pod b/Documentation/lilyinput.pod
index b7d48880064e465b7e4631a5b2a3071bfa5db595..58a4378d4b9ec862f8958a797b2603457a539f4c 100644 (file)
--- a/Documentation/lilyinput.pod
+++ b/Documentation/lilyinput.pod
@@ -70,7 +70,10 @@ Not really crystallized; you can use '#' or '%' as line comment
 LilyPond first reads 'symbol.ini', which contains declarations crucial
 to proper operation of LilyPond (symbol tables, note names).
 
-This language looks a lot like Rayce's which in turn owes a lot to the
-POVRay raytracer. Now, I know, musictypesetting and Raytracing do not
-necessarily require the same input format, but I was just to lazy to
-make up a new and/or better input format. Suggestions appreciated.
+This language looks a lot like Rayce's (Rayce is a raytracer that I've
+written as a hobby project. I used as a practice program for writing
+(among others) C++ and Yacc. It also gave me RSI :-( ) which in turn
+owes a lot to the POVRay raytracer. Now, I know, musictypesetting and
+Raytracing do not necessarily require the same input format, but I was
+just to lazy to make up a new and/or better input format. Suggestions
+appreciated.