From: Graham Percival Date: Mon, 19 Apr 2010 13:27:24 +0000 (+0100) Subject: Doc: remove old automated-engraving. X-Git-Tag: release/2.13.19-1~2^2~14 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=1eb30a8559913b7de7478f4726c95f7fdd24b76e;p=lilypond.git Doc: remove old automated-engraving. --- diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index 973096bf13..d1ffcf4e82 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -9,7 +9,7 @@ depth = .. NAME = documentation LANGS = $(shell $(PYTHON) $(top-src-dir)/python/langdefs.py) -MANUALS_SUBDIRS = usage automated-engraving contributor essay \ +MANUALS_SUBDIRS = usage contributor essay \ web learning notation extending SUBDIRS = $(MANUALS_SUBDIRS) snippets logo pictures misc po css topdocs \ included $(LANGS) diff --git a/Documentation/automated-engraving.itexi b/Documentation/automated-engraving.itexi deleted file mode 100644 index 95b4ea6c39..0000000000 --- a/Documentation/automated-engraving.itexi +++ /dev/null @@ -1,85 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - -@ignore -hmm, the one big page is too big, but it was really inviting to - read. this is not. maybe just scrap this menu and introduction - to index? -@end ignore - -@c @setfilename automated-engraving.info -@c @settitle Obsessed with putting ink on paper -@c @documentencoding UTF-8 -@c @documentlanguage en - -@c @set web -@c @include macros.itexi - -@c @afourpaper - -@c @ifnottex -@c @node Top -@c @top -@c @chapheading -@c @end ifnottex - -@node automated-engraving -@unnumbered Obsessed with putting ink on paper -@c @finalout - -@heading What is behind LilyPond? - -@sourceimage{hader-collage,,,.png} - -LilyPond is not unique in making music notation: there are a lot of -programs that print music, and nowadays most of the newly printed -music is made with computers. Unfortunately, that also shows: just -ask any musician that plays classical music: new scores do not look as -nice as old ones. - -What is the difference between hand-work and machine work, and what -has caused it? How can we improve the situation? This essay explains -problems in music notation (software), and our approach to solving -them. - -@menu -* introduction:: Introduction -- what is wrong with computer music notation. -* software:: What is wrong with software -- or how Finale is not the end-all of music software. -* problem-statement:: How not to design software -- or modeling music notation. -* divide-and-conquer:: Divide and conqueror -- a blue print for automated notation. -* implementing-notation:: Impressive, but does it also work in theory -- a practical approach to capturing notation. -* engraving:: Music engraving -- the art of printing music. -* implementing-typography:: Implementing typography -- hackers attack the engraving problem. -* formatting-architecture:: A flexible program architecture -- lets us write engraving software -* scoring-esthetics:: Beautiful numbers -- how LilyPond participates in the Miss World contests. -* benchmarking:: Notation benchmarking -- is a flexible architecture enough? -* schubert:: Notation benchmarking -- project too? -* typography-features:: Typographical features -- unique to LilyPond. -* input-format:: Input format -- how to enter music. -* conclusion:: Conclusion. -@end menu - -@contents - -@c This essay is also available in @ref{big-page.html,one big page}. - -@include automated-engraving/introduction.itexi -@include automated-engraving/software.itexi -@include automated-engraving/problem-statement.itexi -@include automated-engraving/divide-and-conquer.itexi -@include automated-engraving/implementing-notation.itexi -@include automated-engraving/engraving.itexi -@include automated-engraving/implementing-typography.itexi -@include automated-engraving/formatting-architecture.itexi -@include automated-engraving/scoring-esthetics.itexi -@include automated-engraving/benchmarking.itexi -@include automated-engraving/schubert.itexi -@include automated-engraving/typography-features.itexi -@include automated-engraving/input-format.itexi -@include automated-engraving/conclusion.itexi diff --git a/Documentation/automated-engraving/GNUmakefile b/Documentation/automated-engraving/GNUmakefile deleted file mode 100644 index c93c9e0624..0000000000 --- a/Documentation/automated-engraving/GNUmakefile +++ /dev/null @@ -1,5 +0,0 @@ -depth = ../.. - -LOCALSTEPMAKE_TEMPLATES = ly - -include $(depth)/make/stepmake.make diff --git a/Documentation/automated-engraving/benchmarking.itexi b/Documentation/automated-engraving/benchmarking.itexi deleted file mode 100644 index 2bca988728..0000000000 --- a/Documentation/automated-engraving/benchmarking.itexi +++ /dev/null @@ -1,105 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node benchmarking - -@unnumberedsec Notation benchmarking - -A flexible architecture is necessary for good -formatting. Unfortunately, it is not sufficient. Only a careful -emulation of printed matter will give a good result. We suggested in -the introduction to compare program output with existing hand-engraved -scores. It is exactly this technique that we use to perfect LilyPond -output. In a way, this is a benchmarking technique: the performance of -the program, in terms of quality, is measured in relation to a known -quantity. - -Here you see parts of a benchmark piece. At the top the reference -edition (B@"arenreiter BA 320) at the bottom the output from -LilyPond 1.4: - -@divClass{float-center} -@c @ref{baer-sarabande-hires.png, -@sourceimage{baer-sarabande,,,.png} -@c } -@divEnd - -@divClass{float-center} -B@"arenreiter (click to enlarge) -@divEnd - -@divClass{float-center} -@sourceimage{lily14-sarabande,,,.png} -@divEnd - -@divClass{float-center} -LilyPond 1.4 -@divEnd - -The LilyPond output is certainly readable, and for many people it -would be acceptable. However, close comparison with a hand-engraved -score showed a lot of errors in the formatting details: - -@divClass{float-center} -@sourceimage{lily14-sarabande-correct,,,.png} -@divEnd - -@divClass{float-center} -@itemize -@item - Lots of symbols were unbalanced. In particular the trill sign was -too large. - - -@item - Stems and beams were all wrong: the stems were too long, and -beam should be slanted to cover staff lines exactly. The beam was also -too light. - - -@item - The spacing was irregular: some measures were too tight, other -too wide. - - -@end itemize -@divEnd - -(And there were missing notes in the original version for LilyPond) - -By addressing the relevant algorithms, settings, and font designs, we -were able to improve the output. The output for LilyPond 1.8 is shown -below. Although it is not a clone of the reference edition, this -output is very close to publication quality. - -@divClass{float-center} -@sourceimage{lily17-sarabande,,,.png} -@divEnd - -@divClass{float-center} -LilyPond 1.8 -@divEnd - -@divClass{float-center} -@sourceimage{baer-sarabande,,,.png} -@divEnd - -@divClass{float-center} -B@"arenreiter -@divEnd - -Another example of benchmarking is our project for the 2.1 series, a -@ref{schubert,Schubert song}. - -@divClass{float-right} -Next: @ref{typography-features,Cool features}, -typographical hoops that we made LilyPond jump through. -@divEnd diff --git a/Documentation/automated-engraving/conclusion.itexi b/Documentation/automated-engraving/conclusion.itexi deleted file mode 100644 index 6065bc2528..0000000000 --- a/Documentation/automated-engraving/conclusion.itexi +++ /dev/null @@ -1,34 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node conclusion - -@unnumberedsec Conclusion - -We have shown you what engraved music should look like, and how we built -our software to emulate that look. We have put a lot of effort into -building it. Thanks to all that hard work, you can - -TODO: this whole dir should be deleted; see -http://code.google.com/p/lilypond/issues/detail?id=1017 - -@c @ref{@DEPTH@switch/tour.html,use the program to print nice music too}. - -To complete the reading of this essay, you may want to have a look at - -@c @ref{@DEPTH@about/pubs.html,publications and articles}, -especially @uref{http://www.musicbyandrew.ca/finale-lilypond-1.html,Andrew -Hawryluk's writings}, which include Finale and LilyPond notation -benchmarking. - -@c @divClass{float-right} -@c @divEnd -@c Go @ref{Top,back} to the top. diff --git a/Documentation/automated-engraving/divide-and-conquer.itexi b/Documentation/automated-engraving/divide-and-conquer.itexi deleted file mode 100644 index 631dbece68..0000000000 --- a/Documentation/automated-engraving/divide-and-conquer.itexi +++ /dev/null @@ -1,80 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - -@node divide-and-conquer -@unnumberedsec Plan de campagne - -Since content and form of a score are separate, we have to match that -in the design of software. Hence, the basic blueprint of our program -should follow this scheme - -@multitable @columnfractions .3 .3 .3 -@item - -@sourceimage{simple-notation,,,.png} - - -@tab - -@result{} - - -@tab - -@code{@{ c'4 d'8 @}} - - - - -@item - -1. form - - -@tab - -2. translation - - -@tab - -3. content - - - - -@end multitable - -In effect, we are conquering the problem by dividing it into -subproblems - -@enumerate 1 -@item -Typography: @strong{where} to put symbols - -@item -Notation: @strong{what} symbols to produce -@item -Representation: how to @strong{encode} music -@end enumerate - -Finally, whenever you subdivide a problem, a new problem is created, -@enumerate 4 - - -@item - Architecture: glue everything @strong{together} - -@end enumerate - -@divClass{float-right} -Next: @ref{implementing-notation,Impressive, but does it also -work in theory}? A practical approach to capturing notation. -@divEnd diff --git a/Documentation/automated-engraving/engraving.itexi b/Documentation/automated-engraving/engraving.itexi deleted file mode 100644 index b3248261d0..0000000000 --- a/Documentation/automated-engraving/engraving.itexi +++ /dev/null @@ -1,53 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - -@node engraving -@unnumberedsec Music engraving - -@sourceimage{hader-slaan,,,.png} - - -When we know what symbols to print, we have to decide where to put -them so the the result looks pleasing. This art is called @emph{music -engraving}. The term derives from the traditional process of -music printing. Only a few decades ago, sheet music was made by -cutting and stamping the music into zinc or pewter plates in mirror -image. The plate would be inked, and the depressions caused by the -cutting and stamping would hold ink. An image was formed by pressing -paper to the plate. The stamping and cutting was completely done by -hand. Making corrections was cumbersome, so engraving had to be done -correctly in one go. Of course, this was a highly specialized skill - - -@itemize -@item - Music engraving is a traditional craft, and was learned in -practice. An accomplished master had to complete around 10 years of -practice. - - -@item - Most of the knowledge was passed from master to apprentice during -practical training. Consequently, little has been explicitly laid down -about the rules of elegant engraving. - - -@item - Finally, engraving is about selecting proper distance and -blackness for scores. @sourceimage{stone-distance,,,.png} The -quality of the end result must be judged visually. This is virtually -impossible to capture in formal rules. - - -@end itemize - -@divClass{float-right} -Next: @ref{implementing-typography,Stamping computer -screens?}. Computer hackers take over the engraving business. -@divEnd diff --git a/Documentation/automated-engraving/formatting-architecture.itexi b/Documentation/automated-engraving/formatting-architecture.itexi deleted file mode 100644 index 50ca336a0c..0000000000 --- a/Documentation/automated-engraving/formatting-architecture.itexi +++ /dev/null @@ -1,63 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node formatting-architecture - -@unnumberedsec A flexible formatting architecture - -Remember the music notation problem? Its solution left us with a -bunch of objects. The formatting architecture is built on these -objects. Each object carries variables: - -@itemize -@item - Variables control layout decisions. For example, many objects -have a @code{direction} variable that encodes the choice between up -and down (or left and right). Here you see two chords, with accents -and arpeggio. In the first chord, the objects have all directions down -(or left). The second chord has all directions up (right). - -@divClass{float-center} -@sourceimage{directions-updown,,,.png} -@divEnd - -The process of formatting a score consists of reading and writing -object variables. - - - -@item -Some variables have a preset value. For example, the thickness of - many lines – a characteristic of typographical style – are preset - variables. Changing them gives a different typographical impression: - -@divClass{float-center} -@sourceimage{thickness-tweaks,,,.png} -@divEnd - -@item -Formatting rules are also preset variables: each object has -variables containing procedures. These procedure perform the actual -formatting, and by substituting different ones, we can change -behavior. In the following example, the rule that note head objects -use to draw their symbol is changed during the music fragment: - -@divClass{float-center} -@sourceimage{mc-squared,,,.png} -@divEnd - -@end itemize - -@divClass{float-right} -Next: - @ref{scoring-esthetics,Beautiful numbers}: how -LilyPond participates in the Miss World contests. -@divEnd diff --git a/Documentation/automated-engraving/implementing-notation.itexi b/Documentation/automated-engraving/implementing-notation.itexi deleted file mode 100644 index 029f127020..0000000000 --- a/Documentation/automated-engraving/implementing-notation.itexi +++ /dev/null @@ -1,128 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node implementing-notation - -@unnumberedsec Music notation - -Common music notation encompasses some 500 years of music. Its -applications range from monophonic melodies to monstruous counterpoint -for large orchestras. How can we get a grip on such a many-headed -beast? Our solution is to make a strict distinction between notation, -@emph{what} symbols to use, and engraving, @emph{where} to put -them. For tackling notation, we have broken up the problem into -digestible (and programmable) chunks: every type of symbol is handled -by a separate plugin. All plugins cooperate through the LilyPond -architecture. They are completely modular and independent, so each -can be developed and improved separately. - -@itemize -@item -The most basic plug-in creates Note-heads: - -@divClass{float-center} -@sourceimage{engraver-noteheads,,,.png} -@divEnd - -This plug-in creates graphical objects from musical events. People -that put graphics to musical ideas are called copyists or engravers, -so by analogy, this plug-in is called @code{Note_head_engraver}. - - -@item - The @code{Staff_symbol_engraver} generates the object -representing the staff lines. - -@divClass{float-center} -@sourceimage{engraver-staff,,,.png} -@divEnd - -@item - - The @code{Clef_engraver} tells @code{Note_head_engraver} how high -each head should be placed. - -@divClass{float-center} -@sourceimage{engraver-clef,,,.png} -@divEnd - - - -@item - -For the flags and stems we add a @code{Stem_engraver}: - -@divClass{float-center} -@sourceimage{engraver-stem,,,.png} -@divEnd - -This engraver is notified of any note head coming along. Every time -one (or more, for a chord) note head is seen, a stem object is -created, and attached to the note head. - -@item - -Beams, slurs, accents are handled by separate engravers. Like the -@code{Stem_engraver}, they create objects and connect them to stems, -note heads, etc.: - -@divClass{float-center} -@sourceimage{engraver-slur,,,.png} -@divEnd - - - -@item - -Accidentals, bar lines, time signature, and key signature each have a -separate -engraver. - -@divClass{float-center} -@sourceimage{engraver-acc,,,.png} -@divEnd - -The @code{Accidental_engraver} is the most complex plug-in: it has -to look at the key signature, note pitches, ties, and bar lines to -decide when to print accidentals. - - -@end itemize - - -@c @unnumberedsec Polyphonic notation -@heading Polyphonic notation - -The system shown in the last section works well for monophonic music, -but what about polyphony? In polyphonic notation, many voices can -share a staff: - -@divClass{float-center} -@sourceimage{engraver-final,,,.png} -@divEnd - -In this situation, the accidentals and staff are shared, but the -stems, slurs, beams, etc. are private to each voice. Hence, engravers -should be grouped. The engravers for note head, stems, slurs, etc. go -into a group called "Voice context," while the engravers for key, -accidental, bar, etc. go into a group called "Staff context." In the -case of polyphony, a single Staff context contains more than one Voice -context. Similarly, more Staff contexts can be put into a single -Score context: - -@divClass{float-center} -@sourceimage{engraver-score,,,.png} -@divEnd - -@divClass{float-right} -Next: @ref{engraving,The art of stamping}: -how @emph{did} they make hand-made music? -@divEnd diff --git a/Documentation/automated-engraving/implementing-typography.itexi b/Documentation/automated-engraving/implementing-typography.itexi deleted file mode 100644 index 4acca56577..0000000000 --- a/Documentation/automated-engraving/implementing-typography.itexi +++ /dev/null @@ -1,69 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - - -@node implementing-typography - - -@unnumberedsec Implementing typography - -How do we go about implementing typography? Answering the "music -notation" problem left us with a bunch of graphic objects -representing note heads, the staff, stems, etc. - -If craftsmen need over ten years to become true masters, how could we -simple hackers ever write a program to take over their jobs? - -The answer is: we cannot! Since typography relies on human judgement -of appearance, people cannot be replaced. However, much of their dull -work can be automated: if LilyPond solves most of the common -situations correctly, then this will be a huge improvement over -existing software. The remaining cases can be tuned by hand. -Over the course of years, the software can be refined to do -more and more automatically, so manual overrides are necessary less -and less. - -How do we go about building such a system? When we started, we wrote -the program in C++. Essentially, this means that the program -functionality is set in stone by us developers. That proved to be -unsatisfactory: - -@itemize -@item - If things must be tuned by hand, then the user must access to the - formatting engine. Hence, rules and settings cannot be fixed at - compile time, but they must be accessible at run-time. - - -@item - Engraving is a matter of visual judgement, and hence it is a - matter of taste. As knowledgeable as we are, users can disagree with - our personal decision. Therefore, the definitions of typographical - style must also be accessible to the user. - - -@item - Finally, we continually refine the formatting algorithms, so we - need a flexible approach to rules. The C++ language forces a certain - method of grouping rules that does not match how music notation works. - - -@end itemize - -Clearly, there is a need for a flexible architecture. The architecture -should encompass formatting rules, typographical style and individual -formatting decisions. - -@divClass{float-right} -Next: @ref{formatting-architecture,Program architecture, -your flexible friend}: tuning, tweaking and developing typography -rules. -@divEnd diff --git a/Documentation/automated-engraving/input-format.itexi b/Documentation/automated-engraving/input-format.itexi deleted file mode 100644 index d9e75e7704..0000000000 --- a/Documentation/automated-engraving/input-format.itexi +++ /dev/null @@ -1,156 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node input-format - -@unnumberedsec Input format - -As discussed earlier, the ideal input format for a music engraving -system is the content: the music itself. This poses a formidable -problem: how can we define what music really @emph{is}? Our way out -of this problem, is to reverse it. Instead of defining what music is, -our program serves as a definition: we write a program capable of -producing sheet music, and adjust the format to be as lean as -possible. When the format can no longer be trimmed down, by -definition we are left with content itself. - -The syntax is also the user-interface for LilyPond, hence it is easily -typable, e.g., - -@verbatim - - c'4 d'8 - -@end verbatim -Are a quarter note C1 and eighth note D1, as in this example: - -@divClass{float-center} -@sourceimage{simple-notation,,,.png} -@divEnd - -On a microscopic scale, such syntax is easy to use. On a larger scale, -syntax also needs structure. How else can you enter complex pieces -like symphonies and operas? The structure is formed by the concept of -music expressions: by combining small fragments of music into larger -ones, more complex music can be expressed. For example, - -@multitable @columnfractions .5 .5 -@item - -c4 - -@tab - -@sourceimage{simultaneous-0,,,.png} - - -@end multitable - -Combine this simultaneously with two other notes by enclosing in << -and >>. - -@multitable @columnfractions .5 .5 - -@item - -@verbatim - - <> - -@end verbatim - - -@tab - -@sourceimage{simultaneous-1,,,.png} - - - -@end multitable - -This expression is put in sequence by enclosing it in braces, i.e., -@multitable @columnfractions .5 .5 -@item - -@verbatim - - { <> f4 } -@end verbatim - - -@tab - -@sourceimage{simultaneous-2,,,.png} - - - -@end multitable - -The above is another expression, and therefore, it may be combined -again with a simultaneous expression (in this case, a half note). - -@multitable @columnfractions .5 .5 -@item - -@verbatim - -<< { <> f4 } g2 >> - -@end verbatim - - -@tab - -@sourceimage{simultaneous-3,,,.png} - - - - -@end multitable - -Such recursive structures can be specified neatly and formally in a -@emph{context-free grammar}. The parsing code is also generated -from this grammar. In other words, the syntax of LilyPond is clearly -and unambiguously defined. - -User-interfaces and syntax are what people see and deal with -most. They are partly a matter of taste, and also subject of much -discussion. Although discussions on taste do have their merit, they -are not very productive. In the larger picture of LilyPond, the -importance of input syntax is small: inventing neat syntax is easy, -writing decent formatting code is much harder. This is also -illustrated by the line-counts for the respective components: parsing -and representation take up less than 10% of the code. - -@multitable @columnfractions .5 .5 -@item -Parsing + representation -@tab -@item -total -@tab -@item -6000 lines C++ -@tab -61500 lines C++ -@end multitable - -@ignore - TODO : - - blurbs about lilypond today - - future? -@end ignore - -@divClass{float-right} -Next: @ref{conclusion,wrapping it up}, the conclusion. -@divEnd diff --git a/Documentation/automated-engraving/introduction.itexi b/Documentation/automated-engraving/introduction.itexi deleted file mode 100644 index 68fc8c3e8e..0000000000 --- a/Documentation/automated-engraving/introduction.itexi +++ /dev/null @@ -1,110 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node introduction - -@unnumberedsec What is wrong with computer music notation? - -We like to call LilyPond an "automated engraving system." It will -format music notation beautifully without requiring typographical -expertise of its users. - -LilyPond is not unique in making music notation: there are a lot of -programs that print music, and nowadays most of the newly printed -music is made with computers. Unfortunately, that also shows: just -ask any musician that plays classical music: new scores do not look as -nice as old (from before, say, 1970) scores: the new ones have a -bland, mechanical look. They are not at all pleasurable to play from. - -To illustrate this, take a look at the following examples. Both are -editions of the 1st Cello Suite by J.S.Bach. The one on the left is a -very beautifully hand-engraved edition from 1950, the one on the right -is a typical contemporary computer product. Take a few seconds to let -the looks of both pages sink in. Which one do you like better, and -why? - -@ifnottex -@multitable @columnfractions .5 .5 -@item - -@sourceimage{baer-suite1-fullpage,,,.png} - -@tab - -@sourceimage{henle-suite1-fullpage,,,.png} - - - -@item -B@"arenreiter (BA 320, (c) 1950) - -@tab -Henle (nr. 666 (c) 2000) - -@end multitable -@end ifnottex - -The left picture looks nice: it has flowing lines and movement. It's -music, and it's alive. Now, the picture on the right shows the same -music, and it was written by Bach. His music surely has liveliness -and flowing lines.... Except, the score doesn't show it: it looks -rigid and mechanical. To understand better why that is, let's blow up -a fragment of both pieces: - -@divClass{float-center} -@sourceimage{baer-suite1-line,,,.png} -@divEnd - -@divClass{float-center} -Hand-made -@divEnd - -@* - -@divClass{float-center} -@sourceimage{henle-suite1-line,,,.png} -@divEnd - -@divClass{float-center} -Computer-made -@divEnd - -The location of the bar lines is a giveaway. In the new edition, -both barlines are on exactly the same horizontal location. Also, the -note heads are on the exact same horizontal location. When you look -back at the whole page, you can easily verify that almost all barlines -are in the same location, as are most of the note heads. The entire -thing is spaced as if it were put to a big grid, which is what causes -the mechanical impression. - -This is not the only error on this example, and more importantly, this -piece is not the only one with typographical errors. Sadly, almost -all music printed nowadays is full of basic typographical mistakes. - -Musicians are usually more absorbed with performing the music than -with studying its looks, so this nitpicking about typographical -details may seem academical. That is not justified. This piece here -has a monotonous rhythm. If all lines look the same, they become like -a labyrinth. If the musician looks away once or has a lapse in his -concentration, he will be lost on the page. - -In general, this is a common characteristic of typography. Layout -should be pretty, not only for its own sake, but especially because it -helps the reader in his task. For performance material like sheet -music, this is doubly important: musicians have a limited amount of -attention. The less attention they need for reading, the more they can -focus on playing itself. In other words, better typography translates -to better performances. - -@divClass{float-right} -Next: @ref{software,What is wrong with software}, or how -Finale is not the end-all of music software. -@divEnd diff --git a/Documentation/automated-engraving/problem-statement.itexi b/Documentation/automated-engraving/problem-statement.itexi deleted file mode 100644 index bb5b583709..0000000000 --- a/Documentation/automated-engraving/problem-statement.itexi +++ /dev/null @@ -1,74 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - - -@node problem-statement -@unnumberedsec Designing notation software: how not to do it - -It would be nice if notation software didn't need any babysitting to -produce acceptable output. - -Our goal with @emph{LilyPond} was to write such a system: a program -that will produce beautiful music ("engraving") automatically. - -At first sight, music notation follows a straightforward hierarchical -pattern. Consider the example below, with two staves containing two -measures. - -@sourceimage{naive-notation,,,.png} - -Isn't writing software all about finding hierarchies and modeling the -real world in terms of trees? In the view of a naive programmer, the -above fragment of notation is easily abstracted to a nested set of -boxes - -@sourceimage{naive-notation-uml,,,.png} - -It's easy to follow this model when writing software. It's obvious -how to store this data in memory, and writing on disk can be easily -mirrored. In an XML-file you could write something like - -@verbatim - - - - - - - - - - .... - - - - -@end verbatim - -In short, this model is obvious, simple and neat. It's the format -used by a lot software. Unfortunately, it's also wrong. The -hierarchical representation works for a lot of simpler music, but it -falls apart for advanced use. Consider the following example: - -@sourceimage{nonnaive-notation,,,.png} - -In this example, several assumptions of the previous model are -violated: staves start and stop at will, voices jump around between -staves, and sometimes span two staves. - -Music notation is really different from music itself. Notation is an -intricate symbolic diagramming language for visualizing an often much -simpler musical concept. Hence, software should reflect that separation. - -@divClass{float-right} -Next: @ref{divide-and-conquer,Divide and conqueror}, -a blue print for automated notation -@divEnd diff --git a/Documentation/automated-engraving/schubert.itexi b/Documentation/automated-engraving/schubert.itexi deleted file mode 100644 index 2f39aa1807..0000000000 --- a/Documentation/automated-engraving/schubert.itexi +++ /dev/null @@ -1,41 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - -@node schubert -@unnumberedsec S@"angers Morgenlied, by Franz Schubert - -The benchmarking project for the LilyPond 2.1.x series, was the -Ed. Peters version of a Schubert song. - -The result of 2.1.5 was nice, but certainly not perfect, - -@sourceimage{bench-morgenlied,,,.png} - -Here is the original, - -@sourceimage{morgenlied-crop-2,,,png} - -and the result of LilyPond 2.1.35. - -@sourceimage{morgenlied-ly-crop2,,,.png} - -This is a page from a song-book, which is printed in a smaller format. -Normal print uses 20 pt staff height, this uses 17 pt. In smaller -print, staff lines should be relatively thicker. To match the thicker -lines, the music symbols should also be relatively heavier. Both have -been implemented in LilyPond 2.1. The difference is hard to see here, -due to the limited resolution of computer screens. For a more detailed -view, see the LilyPond PDF, available - -@uref{http://lilypond.org/documentation/v2.2/input/mutopia/F.Schubert/out-www/morgenlied.pdf,here}. - -@divClass{float-right} -@ref{benchmarking,Back to the essay} -@divEnd diff --git a/Documentation/automated-engraving/scoring-esthetics.itexi b/Documentation/automated-engraving/scoring-esthetics.itexi deleted file mode 100644 index 1adc5eff72..0000000000 --- a/Documentation/automated-engraving/scoring-esthetics.itexi +++ /dev/null @@ -1,100 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - -@node scoring-esthetics -@unnumberedsec Beautiful numbers - -How do we actually make formatting decisions? In other words, which -of the three configurations should we choose for the following slur? - -@sourceimage{slur-esthetics,,,.png} - -There are a few books on the art of music engraving -available. Unfortunately, they contain rules of simple thumbs and some -examples. Such rules can be instructive, but they are a far cry from -an algorithm that we could readily implement in a computer. Following -the instructions from literature leads to algorithms with lots of -handcoded exceptions. Doing all this case analysis is a lot of work, -and often not all cases are covered completely. - -@divClass{float-center} -@sourceimage{ross-beam-scan,,,.png} -@divEnd - -@divClass{float-center} -@emph{Formatting rules defined by example. Image from Ted Ross' The Art of -Music Engraving} -@divEnd - -We have developed a much easier and robust method of determining the -best formatting solution: score based formatting. The principle is the -same as a beauty contest: for each possible configuration, we compute an -ugliness score. Then we choose the least ugly configuration. - -@sourceimage{slur-esthetics-annotate-1,,,.png} - -For example, in the above configuration, the slur nicely connects the -starting and ending note of the figure, a desirable trait. However, it -also grazes one note head closely, while staying away from the others. -Therefore, for this configuration, we deduct a `variance' score of -15.39. - -@sourceimage{slur-esthetics-annotate-2,,,.png} - -In this configuration, the slur keeps a uniform distance from the -heads, but we have to deduct some points because the slur doesn't -start and end on the note heads. For the left edge, we deduct 1.71, -and for the right edge (which is further from the head) we deduct 9.37 -points. - -Furthermore, the slur goes up, while the melody goes down. This incurs -a penalty of 2.00 points - -@sourceimage{slur-esthetics-annotate-3,,,.png} - -Finally, in this configuration, only the ending the slur is far away -from the ending note head, at a score of 10.04 ugliness points. - -Adding up all scores, we notice that the third option is the least -ugly, or most beautiful version. Hence we select that one. - -This technique is a general technique, and it is used in a lot of -situations, for example - -@itemize -@item - determining beam slopes - -@sourceimage{beam-scoring-example,,,.png} - -@item - formatting tied chords - -@sourceimage{ties-scoring-example,,,.png} -@item - formatting dotted chords - - -@item - line breaking - -@item - page breaking - -@end itemize - -This technique evaluates a lot of possibilities, which takes some time -to compute. However, that is a worthwhile expense, because the end -result is much better, and because it makes our lives easy. - -@divClass{float-right} -Next: @ref{benchmarking,Man is the measure of things}: is a -flexible architecture enough? -@divEnd diff --git a/Documentation/automated-engraving/software.itexi b/Documentation/automated-engraving/software.itexi deleted file mode 100644 index 0c494d8f2f..0000000000 --- a/Documentation/automated-engraving/software.itexi +++ /dev/null @@ -1,110 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node software -@unnumberedsec What is wrong with music notation software - -Computers have made music printing accessible to the masses, but they -tend to deliver mediocre typography. Apparently, programmers have -been doing a shoddy job on notation programs. To illustrate that, we -had an amateur user set a piece of music in one of the most popular -@quotedblleft{}professional@quotedblright{} notation programs sold today, Finale -2003. It was made with all of the default settings. The music is from -the Sarabande of the 2nd Cello Suite by J. S. Bach. - -@emph{ -(Finale is a registered trademark of MakeMusic! Inc.) -} - -@divClass{float-center} -@sourceimage{finale-sarabande-full,,,.png} -@divEnd - -This example far surpasses the previous one when it comes to -formatting errors: there are serious errors in literally -@emph{every} measure. The errors come in all sizes: a big one is the -oddly s p a c e d @ o u t last line. A smaller one is the flat in -measure 13, which is covered by the note preceding it. Here is a -magnification of that measure: - -@divClass{float-center} -@sourceimage{finale-flat-detail,,,.png} -@divEnd - -The errors go down to the teensy details: below is a blowup of the -beam in that measure. Of course, in proper typography the beam should -not stick out to the right of the stem, and the ribbles provide a -telling glimpse into Coda Music Technology programmers' aptness (or -lack thereof) with the underlying PostScript technology. - -@divClass{float-center} -@sourceimage{finale-beam-detail,,,.png} -@divEnd - -Now, one could refute that Finale has a graphical interface, and it -lets you easily move about elements to correct errors, or use plug-ins -to do so. This is certainly true: in fact, good professional -engravers that use Finale typically spend the majority of their time -correcting all the errors that Finale routinely makes. But do you -want to spend your time on correcting all glaring errors? For the -spaced out line, it is doable, but imagine that you have to correct -each and every beam that sticks out of the stems.... by hand? - -There is a less obvious reason why correcting things by hand is a bad -idea. Consider again measure 13 reproduced above. The misplaced flat -is pretty obvious, but did you notice that repeat bar? Its lines are -too far apart. Did you notice that the eighth rest is too far down? -Did it occur to you that the stem of the last eighth note is too long? - -@divClass{float-center} -@sourceimage{finale-flat-correct,,,.png} -@divEnd - -Unless you are an expert, typographical errors will irk you without -being obvious. Many of them will go uncorrected and will still be in the -final print. - -This example may seem contrived, but in fact, it's not. All -major producers of notation software claim to follow engraving -standards, but we have not seen any that gets the basics right; all of -them make systematic mistakes. If you want to assess the output of your -favorite program, then buy a decent hand-made score from a respectable -publisher, and try to reproduce one page of it. Then compare them: - -@itemize -@item - -How does the page layout compare? Typically, computer scores are more -widely spaced so they take up more pages, meaning more annoying page -turns. - - -@item - -How does the spacing compare? Is it as lively and flowing as the -hand-made score? If in doubt, try measuring both with a ruler. - - -@item - -Put both on a music stand, 1 meter away; that is not uncommon when -performing. Can you read both pages? Almost all computer scores have -an anemic look: they use lines which are too thin, and symbols which -are too light. That makes them hard to read from a distance. If in -doubt, measure the difference with a magnifying glass. - - -@end itemize - -@divClass{float-right} -Next: @ref{problem-statement,How not to design software}, -or: modeling music notation. -@divEnd diff --git a/Documentation/automated-engraving/typography-features.itexi b/Documentation/automated-engraving/typography-features.itexi deleted file mode 100644 index 2954a7c253..0000000000 --- a/Documentation/automated-engraving/typography-features.itexi +++ /dev/null @@ -1,130 +0,0 @@ -@c -*- coding: utf-8; mode: texinfo; -*- -@ignore - Translation of GIT committish: FILL-IN-HEAD-COMMITTISH - - When revising a translation, copy the HEAD committish of the - version that you are working on. For details, see the Contributors' - Guide, node Updating translation committishes.. -@end ignore - - - -@node typography-features - -@unnumberedsec Font design - -A large factor that makes LilyPond output look traditional lies in the -blackness of the page. By using heavy stafflines, and a font design to -match that, the overall impression is much stronger. This is also very -clear from the following blowups: - -@multitable @columnfractions .3 .3 .3 -@item - -@sourceimage{henle-flat-gray,,,.png} - -@tab - -@sourceimage{baer-flat-gray,,,.png} - -@tab - -@sourceimage{lily-flat-bw,,,.png} - - -@item -Henle (2000) - -@tab -B@"arenreiter (1950) - -@tab -LilyPond (2003) - - - -@end multitable - -Another typical aspect of hand-engraved scores is the general look of -the symbols. They almost never have sharp corners. This is because -sharp corners of the punching dies are fragile and quickly wear out -when stamping in metal. The general rounded shape of music symbols is -also present in all glyphs of our "Feta" font. - - - - -@c @unnumberedsec Spacing -@heading Spacing - -One of the problems that the Bach piece above inspired us to attack -is the spacing engine. One of its features is optical spacing. -It is demonstrated in the fragment below. - -@divClass{float-center} -@sourceimage{spacing-with-corr,,,.png} -@divEnd - -@divClass{float-center} -@sourceimage{spacing-no-corr,,,.png} -@divEnd - -This fragment only uses quarter notes: notes that are played in a -constant rhythm. The spacing should reflect that. Unfortunately, the -eye deceives us a little: not only does it notice the distance between -note heads, it also takes into account the distance between -consecutive stems. As a result, the notes of an up-stem/down-stem -combination should be put farther apart, and the notes of a down-up -combination should be put closer together, all depending on the -combined vertical positions of the notes. The top fragment is printed -with this correction, the bottom one without. In the last case, the -down-stem/up-stems combinations form clumps of notes. - - -@c @unnumberedsec Ledger lines -@heading Ledger lines - -Ledger lines are typographically difficult. They can easily blot -together with other signs, such as ledger lines or -accidentals. Other software prevents these collisions by spacing the -lines wider (thus taking up more space), or shortening ledger lines -(which hampers readability.) - -@multitable @columnfractions .3 .3 .3 -@item - -@sourceimage{henle-ledger,,,.png} - -@tab - -@sourceimage{baer-ledger,,,.png} - - - -@tab - -@sourceimage{lily-ledger,,,.png} - - -@item -Henle (2000) - -@tab -B@"arenreiter (1950) - -@tab -LilyPond (2004) - - - -@end multitable - -Traditional engravers would adjust the size of a ledger line, -depending on what symbols were in the neighborhood. LilyPond does the -same. Ledgers are shortened so they never collide with neighboring -lines, and they are shortened when there is an accidental. - -@divClass{float-right} -Next: @ref{input-format,Use the Source Luke}, or: what -goes into LilyPond. -@divEnd