From e10cf4cd2498aa0788de6880c395a55813826475 Mon Sep 17 00:00:00 2001 From: fred Date: Sun, 24 Mar 2002 19:48:44 +0000 Subject: [PATCH] lilypond-0.0.76 --- Documentation/AUTHORS.pod | 7 +- Documentation/lilygut.pod | 115 ++++++++++++------------------- Documentation/lilyliterature.pod | 20 +++--- 3 files changed, 61 insertions(+), 81 deletions(-) diff --git a/Documentation/AUTHORS.pod b/Documentation/AUTHORS.pod index d79edec206..dd150709fc 100644 --- a/Documentation/AUTHORS.pod +++ b/Documentation/AUTHORS.pod @@ -23,7 +23,7 @@ Jan Nieuwenhuizen , http://www.digicash.com/~jan lily/midi-*, mi2mu/*, parts flower/string*.cc, make/*.make, */Makefile parts of Documentation/mudela.pod, lib/*source-file*, lib/duration.cc, lib/source, flower/*{list,cursor}*, lily/rest-collision*, conflily, -cygnus w32 stuff +cygnus w32 stuff, lily/*perf* and corresponding header files. @@ -45,3 +45,8 @@ Beam and Stem code. =back +Your name could be here! If you want to help, then take a look at the +SMALLISH PROJECTS section of in the file F. Some do not involve +coding C++ + + diff --git a/Documentation/lilygut.pod b/Documentation/lilygut.pod index ef3249ec8a..f84120b47b 100644 --- a/Documentation/lilygut.pod +++ b/Documentation/lilygut.pod @@ -12,7 +12,7 @@ You should use doc++ to take a peek at the sources. This should become a Hacking-HOWTO. If you find any confusing stuff here, let me know. I am a hacker, and don't spend enough time doccing -what I write. +what I write. (Most stuff here which refers to the code is slightly outdated) If you finally have mastered some internal piece of lily, your explanation could be added here. @@ -41,16 +41,22 @@ Performers), which swallow requests, broadcast them and couple different elements. In this step data-structures for the next steps are created and filled -with data: PScore, PCol. +with data: Score_elements, PScore, PCol. + +=item Prebreaking + +Breakable stuff (eg. clefs and bars) are copied into pre and postbreaks. =item Preprocessing Some dependencies are resolved, such as the direction of stems, beams, -=item Calculation: +=item Break calculation: + +The lines and horizontal positions of the columns are determined + +=item Breaking -This step uses structures which have names starting with 'P'. -linebreaks and horizontal positions of PCols are determined. Through some magical interactions with Line_of_score and Super_elem (check out the source) the "lines" are produced. @@ -67,12 +73,11 @@ are determined. =item Output paper -Very simple, just walk all Line_of_* and follow the links over there =item Output midi -The columns of requests (from the Setting up step) are used to -determine what to output when. +The music is run through a translator (called Performer) which +creates midi-items from the requests. =back @@ -87,22 +92,16 @@ In music typesetting, the user might want to cram a lot more symbols on the paper than actually fits. To reflect this idea (the user asks more than we can do), the container for this data is called Request. -A request is done to the C which contains the -C. The staff 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) +The music (requests) are read/interpreted by a set of objects +(translators), the Performers/Engravers. 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). The result of a request will be an C or a C, which -will be put on a C. Note that the C and the original -C need not have anything in common. For example, the -``double'' piano Staff could interpret commands which juggle -melodies across the left and right hand, and may put the result in -two five-line PStaffs (maybe with extra PStaffs to carry the dynamic -signs and any lyric. - -The class C should be thought as a container for the -Cs, and an interpreter for Cs. +will be put on the score. + Different staffs can produce different outputs; a melodious voice which is put into a percussion-Staff, will be typeset as the rythm of that voice. @@ -122,13 +121,13 @@ some voice elts. =item C -Staff has to decide if the ball should be hanging left or right. This -influences the horizontal dimensions of a column, and this is why -request processing should be done before horizontal spacing. +LilyPond has to decide if the ball should be hanging left or +right. This influences the horizontal dimensions of a column, and this +is why request processing should be done before horizontal spacing. Other voices' frivolities may cause the need for accidentals, so this -is also for the C to decide. The C can decide on positioning -based on ottava commands and the appropriate clef. +is also for the to decide. The engraver can decide on positioning based on +ottava commands and the appropriate clef. =item C @@ -142,7 +141,7 @@ This type of request typically results in the creation of a C Start/stop a beam. -Staff has to combine this request with the stem_request, since the +Engraver has to combine this request with the stem_request, since the number of flags that a stem wants to carry will determine the number of beams. @@ -176,19 +175,19 @@ Voice_group), so they should share the beams, and the two [ ] pairs should be merged. The slurs OTOH are specific for each voice, so they should not be shared. -The judge in this "allocation" problem is Staff (actually, it's child -C). It uses the C to do most of the -work. For each request C queries so-called -Cs if they want to accept a request eg, the -C will accept Cs, and turn down -Cs. If C cannot find a engraver that wants -the request, it is junked (with a warning message). +The judge in this "allocation" problem a set of broker. It uses the +C to do most of the work. For each request +C queries so-called Cs if they want +to accept a request eg, the C will accept +Cs, and turn down Cs. If the Music_iterator +cannot find a engraver that wants the request, it is junked (with a +warning message). After all requests have been either assigned, or junked, the Engraver will process the requests (which usually means creating an C or C). If a C creates something, it tells -C. If all requests have been processed, then each -Engraver is notified of any created Staff_element. +If all requests have been processed, then each Engraver is notified +of any created Score_element, via a broadcasting system. =head2 example: @@ -202,41 +201,13 @@ produces: note_request will be taken by a C, stem_request will be taken by a C. C creates a C, C creates a C. Both announce -this to the Staff. Staff will tell C about the -C, which will add the C to the C it just -created. +this to the Staff_engraver. Staff_engraver will tell +C about the C, which will add the +C to the C it just created. To decide on merging, C has grouped several -engravers. There are a few groups: - -=over 4 - -=item * - -Staff wide, contains - - Local_key_engraver - Bar_engraver - Key_engraver - Meter_engraver - Clef_engraver +engravers. Please check init/engraver.ini. -=item * - -Voice group, contains - - Stem_beam_engraver - Script_engraver - Text_engraver - -=item * - -Voice, contains - - Slur_engraver - Notehead_engraver - -=back =head1 ITEMS and SPANNERS @@ -346,8 +317,12 @@ uses the concept of pre- and post-breaks. minimum distance to other columns, to prevent symbols from running into symbols of other columns.) + +=head1 SPACING 2 + + This of course does not solve the problem of generating the springs. This is an area that needs a lot of work, and the optimal solution to find is not of a mathematical nature. - +Gourlay's solution is used. diff --git a/Documentation/lilyliterature.pod b/Documentation/lilyliterature.pod index dd8c40f20d..a4abb247a5 100644 --- a/Documentation/lilyliterature.pod +++ b/Documentation/lilyliterature.pod @@ -7,8 +7,9 @@ Lily Literature -- reading on music engraving/typesetting/etc. A list of resources on music printing/writing and engraving. Please note that don't have access to most material. -[What I do know, I've commented inside brackets. They are just my -personal comments, not to be taken too seriously] +[Personal comments appear in brackets. What I (HWN) know, I've +commented myself. They are just my personal comments, not to be taken +too seriously] =head2 Music engraving: references @@ -81,8 +82,9 @@ John S. Gourlay. ``Spacing a Line of Music,'' Technical Report OSU-CISRC-10/87-TR35, Department of Computer and Information Science, The Ohio State University, 1987. -[Algorithm to generate spacing in polyphonic music, tailored for use -with MusiCopy HWN] +[Algorithm for generating spacing in one line of (polyphonic) music, +tailored for use with MusiCopy. LilyPond uses a variant of it (as of +pl 76) HWN] Allen Parish, Wael A. Hegazy, John S. Gourlay, Dean K. Roush and F. Javier Sola. ``MusiCopy: An automated Music Formatting System''. @@ -188,7 +190,7 @@ Muziek'' afstudeerscriptie Bestuurlijke informatica, no 45327, Erasmus universiteit Rotterdam, 1991. (``An automated system for printing music'' Master's Thesis Managerial Computer Science.) -[This thesis describes a simplistic (monophonic) typesetting system, +[This dutch thesis describes a simplistic (monophonic) typesetting system, and focuses on the breaking algorithm, which is taken from Hegazy & Gourlay HWN] @@ -261,12 +263,10 @@ Software Inc., 1995. ftp://blackbox.cartah.washington.edu/pub/ [Specs for NIFF, a comprehensive but binary (yuk) format for notation HWN] -Alexander Brinkman, ``PASCAL Programming for Music Research''. The -University of Chicago Press, 1990. - =head1 AUTHORS -References contributed by Han-Wen Nienhuys, Miguel Filgueiras, Mark -Basinski, Dorothea Blostein, Stephen Page, Jan Nieuwenhuizen. +References and comments contributed by Han-Wen Nienhuys (HWN), Miguel +Filgueiras, Mark Basinski (MB), Dorothea Blostein, Stephen Page (SP), +Jan Nieuwenhuizen. This should really be redone in BibTeX -- 2.39.5