Documentation/MANIFESTO.pod

   1 =head1 NAME
   2
   3 MANIFESTO -- Rationale behind the GNU LilyPond project
   4
   5 =head1 DESCRIPTION
   6
   7
   8 GNU LilyPond was written with some considerations in mind:
   9
  10
  11 =over 4
  12
  13 Describing a well-defined language for defining music. We call
  14 this language (rather arrogantly) The Musical Definition Language
  15 (mudela for short). GNU LilyPond reads a mudela sourcefile and outputs a
  16 TeX file.
  17
  18 =item *
  19
  20 We want to provide an easy-to-use interface for typesetting music in
  21 its broadest sense. This interface should be intuitive from a musical
  22 point of view. By broadest sense we mean: it is designed for music
  23 printed left to right in staffs, using notes to designate rythm and
  24 pitch.
  25
  26 =item  *
  27
  28 Generate high-quality output. Ideally it should be of a professional
  29 quality. We'd like to render Herbert Chlapiks words, "Fine music
  30 setting is not possible without a knowledgeable printer,"  untrue.
  31
  32 =back
  33
  34 =head1 LILYPOND
  35
  36
  37 Further considerations while doing the programming
  38
  39 =over 4
  40
  41 =item *
  42
  43 GNU LilyPond uses MusiXTeX fonts and TeX for its output. This is not a key
  44 issue: in a future version, GNU LilyPond might bypass TeX, but at the moment
  45 TeX is very convenient for producing output.
  46
  47
  48 =item *
  49
  50 GNU LilyPond does not display notes directly, nor will it be rehacked to be
  51 used interactively. GNU LilyPond writes output to a file.  It will not be
  52 extended to play music, or to recognize music.
  53
  54 =item *
  55
  56 GNU LilyPond is intended to run on Unix platforms, but it should
  57 be portable to any platform which can run TeX and the GNU tools
  58
  59 =item *
  60
  61 GNU LilyPond is free. Commercial windows packages for setting music are
  62 abundant. Free musicprinting software is scarce.
  63
  64 =item *
  65
  66 GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit
  67 broken systems.
  68
  69 =back
  70
  71 =head1 MUDELA
  72
  73 The design of Mudela has been (perfect past tense, hopefully) an
  74 ongoing process, the most important criteria being:
  75
  76 =over 4
  77
  78 =item *
  79
  80 define the (musical) message of the composer as unambiguously as possible,
  81
  82 =item *
  83
  84 be intuitive, and easily readable
  85 (compared to, say, Musi*TeX input, or MIDI :-),
  86
  87 =item *
  88
  89 be writable in ASCII with a simple texteditor, yfte(TM).
  90
  91 =back
  92
  93 Other considerations were (and will be):
  94
  95 =over 4
  96
  97 =item *
  98
  99 be able to edit the layout without danger of changing the original
 100 music (Urtext),
 101
 102 =item *
 103
 104 allow for adding different interpretations, again,
 105 without danger of changing the original,
 106
 107 =item *
 108
 109 easy to create a conductor's score,
 110 as well as the scores for all individual instruments,
 111
 112 =item *
 113
 114 provide simple musical manipulations, such as
 115 S<(i) extracting> a slice of music from a previously defined piece,
 116 S<(ii) extracting> only the rhythm from a piece of music,
 117 S<(iii) transposing>, etc.,
 118
 119 =item *
 120
 121 easy to comprehend to both programmers and others.
 122
 123 =back
 124
 125 One of the things that (might) be here would be: feasible to use in a
 126 graphic editor. We don't have experience with these beasts, so we
 127 don't know how to do this. Comments appreciated.
 128
 129 Musical pieces could be
 130
 131 =over 4
 132
 133 =item *
 134
 135 Mahlerian orchestral scores,
 136
 137 =item *
 138
 139 piano pieces (Schubertian, Rachmaninovian),
 140
 141 =item *
 142
 143 pop songs (lyrics and chords),
 144
 145 =item *
 146
 147 gregorian chants,
 148
 149 =item *
 150
 151 Bach multivoice organ pieces,
 152
 153 =item *
 154
 155 short excerpts to be used in musicological publications.
 156
 157 =back