summaryrefslogtreecommitdiff
path: root/Documentation/automated-engraving/problem-statement.itexi
diff options
context:
space:
mode:
authorJan Nieuwenhuizen <janneke@gnu.org>2009-08-12 23:38:28 +0200
committerJan Nieuwenhuizen <janneke@gnu.org>2009-08-13 01:30:27 +0200
commit480e203052571809f1a11ee7c7728f08aa042fe9 (patch)
treec56af9445286eb71c8b92b63cc052f3fc8c472a4 /Documentation/automated-engraving/problem-statement.itexi
parent6881f8675f87ab0830dbccfaeeab30207552317d (diff)
Doc: Add converted essay.
Diffstat (limited to 'Documentation/automated-engraving/problem-statement.itexi')
-rw-r--r--Documentation/automated-engraving/problem-statement.itexi76
1 files changed, 76 insertions, 0 deletions
diff --git a/Documentation/automated-engraving/problem-statement.itexi b/Documentation/automated-engraving/problem-statement.itexi
new file mode 100644
index 0000000000..d4219dbe77
--- /dev/null
+++ b/Documentation/automated-engraving/problem-statement.itexi
@@ -0,0 +1,76 @@
+\input texinfo @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. See TRANSLATION for details.
+@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.
+
+@image{pictures/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
+
+@image{pictures/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
+
+ &lt;score&gt;
+ &lt;staff&gt;
+ &lt;measure id="1"&gt;
+ &lt;chord length="1/2"&gt;
+ &lt;pitch name="c"&gt;
+ &lt;/chord&gt;
+ &lt;chord&gt;
+
+ ....
+ &lt;/measure&gt;
+ &lt;/staff&gt;
+ &lt;/score&gt;
+
+@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:
+
+@image{pictures/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}
+@divEnd
+Next: @ref{divide-and-conquer.html,Divide and conqueror},
+a blue print for automated notation
+
+@bye
+