3 MANIFESTO -- Rationale behind the GNU LilyPond project
8 GNU LilyPond was written with some considerations in mind:
15 Describing a well-defined language for defining music. We call
16 this language (rather arrogantly) The Musical Definition Language
17 (mudela for short). GNU LilyPond reads a mudela sourcefile and outputs a
22 We want to provide an easy-to-use interface for typesetting music in
23 its broadest sense. This interface should be intuitive from a musical
24 point of view. By broadest sense we mean: it is designed for music
25 printed left to right in staffs, using notes to designate rythm and
30 Generate high-quality output. Ideally it should be of a professional
31 quality. We'd like to render Herbert Chlapiks words, "Fine music
32 setting is not possible without a knowledgeable printer," untrue.
36 Make a system which is fully tweakable. It should be possible to
37 typeset a book on how not to typeset music.
44 Further considerations while doing the programming
50 GNU LilyPond uses MusiXTeX fonts and TeX for its output. This is not a key
51 issue: in a future version, GNU LilyPond might bypass TeX, but at the moment
52 TeX is very convenient for producing output.
56 GNU LilyPond does not display notes directly, nor will it be rehacked to be
57 used interactively. GNU LilyPond writes output to a file. It will not be
58 extended to play music, or to recognize music.
62 GNU LilyPond is intended to run on Unix platforms, but it should
63 be portable to any platform which can run TeX and the GNU tools
67 GNU LilyPond is free. Commercial windows packages for setting music are
68 abundant. Free musicprinting software is scarce.
72 GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit
79 The design of Mudela has been (perfect past tense, hopefully) an
80 ongoing process, the most important criteria being:
86 define the (musical) message of the composer as unambiguously as possible.
88 This means that, given a piece Mudela, it should be possible for a
89 program to play a reasonable interpretation of the piece.
91 It also means that, given a piece of Mudela, it should be possible for a
92 program to print a score of the piece.
96 be intuitive, and easily readable (compared to, say, Musi*TeX input,
101 be easily writable in ASCII with a simple texteditor, yfte(TM).
105 Other considerations were (and will be):
111 be able to edit the layout without danger of changing the original
116 allow for adding different interpretations, again,
117 without danger of changing the original,
121 easy to create a conductor's score,
122 as well as the scores for all individual instruments,
126 provide simple musical manipulations, such as
127 S<(i) extracting> a slice of music from a previously defined piece,
128 S<(ii) extracting> only the rhythm from a piece of music,
129 S<(iii) transposing>, etc.,
133 easy to comprehend to both programmers and others.
137 One of the things that (might) be here would be: feasible to use in a
138 graphic editor. We don't have experience with these beasts, so we
139 don't know how to do this. Comments appreciated.
141 Musical pieces could be
147 Mahlerian orchestral scores,
151 piano pieces (Schubertian, Rachmaninovian),
155 pop songs (lyrics and chords),
163 Bach multivoice organ pieces,
167 Short excerpts to be used in musicological publications.