-The cause of this problem is that music is inherently two-dimensional:
-in polyphonic music, notes have time and pitch as their two
-coordinates, and they often are related in both directions. Computer
-files on the other hand are essentially one-dimensional: they are a
-long stream of characters. When you represent music in a file, then
-you have to flatten this two-dimensional information breaking either
-timing or pitch relations, and there is no universal agreement on how
-to do this.
-
-Luckily, our application has guided us a little with the design of the
-format: we want to produce a printed score from a music
-representation. A music representation is about @emph{music}, so it
-should be free from notation as much as possible: the format is about
-pitches and durations, not about symbols and offsets. Since LilyPond
-is a compiler, the input format is its user interface, and users have
-to key in the music into the file directly, requiring that the input
-format has a friendly syntax. We, as programmers and scientists want a
-clean formal definition. After all, producing music notation is a
-difficult problem, and in the scientific world, difficult problems
-always must be well-specified. Moreover, formally defined formats are
-easier to write programs for. Finally, enough information should be
-present to be able to produce a printed score.
-
-These ideas shaped our music representation which elegantly builds
-complex musical constructs from simple entities like notes and rests,
-in much the same way that one builds complex formulae from simple
-expressions such as numbers and mathematical operators. The strict
-separation between musical information and typesetting also gives a
-blueprint of the program: first it reads the music representation,
-then it interprets the music---reading it `left-to-right', and
-translating the musical information to a layout specification. When
-the layout is computed, the resulting symbols are written to an output
-file.
+This problem is caused by the two-dimensional nature of music: in
+polyphonic music, notes have time and pitch as their two coordinates,
+and they often are related in both directions. Computer files on the
+other hand are essentially one-dimensional: they are a long stream of
+characters. When you represent music in a file, then you have to
+flatten this two-dimensional information breaking either timing or
+pitch relations, and there is no universal agreement on how to do
+this.
+
+Fortunately, we have a concrete application, so we don't run the risk
+of loosing ourselves in philosophical arguments over the essence of
+music. We want to produce a printed score from a music
+representation, so this gives us a nice guide for designing a format:
+we need a format containing mainly musical elements, such as pitch and
+duration, but also enough information to print a score. Our users
+have to key in the music into the file directly, so the input format
+should have a friendly syntax. Finally, we as programmers and
+scientists want a clean formal definition. After all, producing music
+notation is a difficult problem, and in the scientific world, problems
+can only be solved if they are well-specified. Moreover, formally
+defined formats are easier to write programs for.
+
+These ideas shaped our music representation: it is a compact format
+that can easily be typed by hand. It complex musical constructs from
+simple entities like notes and rests, in much the same way that one
+builds complex formulas from simple expressions such as numbers and
+mathematical operators. The strict separation between musical
+information and typesetting also gives a blueprint of the program:
+first it reads the music representation, then it interprets the
+music---reading it `left-to-right', and translating the musical
+information to a layout specification. When the layout is computed,
+the resulting symbols are written to an output file.