--- /dev/null
+=head1 NAME
+
+MANIFESTO -- Rationale behind the GNU LilyPond project
+
+=head1 DESCRIPTION
+
+
+GNU LilyPond was written with some considerations in mind:
+
+
+=over 4
+
+Describing a well-defined language for defining music. We call
+this language (rather arrogantly) The Musical Definition Language
+(mudela for short). GNU LilyPond reads a mudela sourcefile and outputs a
+TeX file.
+
+=item *
+
+We want to provide an easy-to-use interface for typesetting music in
+its broadest sense. This interface should be intuitive from a musical
+point of view. By broadest sense we mean: it is designed for music
+printed left to right in staffs, using notes to designate rythm and
+pitch.
+
+=item *
+
+Generate high-quality output. Ideally it should be of a professional
+quality. We'd like to render Herbert Chlapiks words, "Fine music
+setting is not possible without a knowledgeable printer," untrue.
+
+=back
+
+=head1 LILYPOND
+
+
+Further considerations while doing the programming
+
+=over 4
+
+=item *
+
+GNU LilyPond uses MusiXTeX fonts and TeX for its output. This is not a key
+issue: in a future version, GNU LilyPond might bypass TeX, but at the moment
+TeX is very convenient for producing output.
+
+
+=item *
+
+GNU LilyPond does not display notes directly, nor will it be rehacked to be
+used interactively. GNU LilyPond writes output to a file. It will not be
+extended to play music, or to recognize music.
+
+=item *
+
+GNU LilyPond is intended to run on Unix platforms, but it should
+be portable to any platform which can run TeX and the GNU tools
+
+=item *
+
+GNU LilyPond is free. Commercial windows packages for setting music are
+abundant. Free musicprinting software is scarce.
+
+=item *
+
+GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit
+broken systems.
+
+=back
+
+=head1 MUDELA
+
+The design of Mudela has been (perfect past tense, hopefully) an
+ongoing process, the most important criteria being:
+
+=over 4
+
+=item *
+
+define the (musical) message of the composer as unambiguously as possible,
+
+=item *
+
+be intuitive, and easily readable
+(compared to, say, Musi*TeX input, or MIDI :-),
+
+=item *
+
+be writable in ASCII with a simple texteditor, yfte(TM).
+
+=back
+
+Other considerations were (and will be):
+
+=over 4
+
+=item *
+
+be able to edit the layout without danger of changing the original
+music (Urtext),
+
+=item *
+
+allow for adding different interpretations, again,
+without danger of changing the original,
+
+=item *
+
+easy to create a conductor's score,
+as well as the scores for all individual instruments,
+
+=item *
+
+provide simple musical manipulations, such as
+S<(i) extracting> a slice of music from a previously defined piece,
+S<(ii) extracting> only the rhythm from a piece of music,
+S<(iii) transposing>, etc.,
+
+=item *
+
+easy to comprehend to both programmers and others.
+
+=back
+
+One of the things that (might) be here would be: feasible to use in a
+graphic editor. We don't have experience with these beasts, so we
+don't know how to do this. Comments appreciated.
+
+Musical pieces could be
+
+=over 4
+
+=item *
+
+Mahlerian orchestral scores,
+
+=item *
+
+piano pieces (Schubertian, Rachmaninovian),
+
+=item *
+
+pop songs (lyrics and chords),
+
+=item *
+
+gregorian chants,
+
+=item *
+
+Bach multivoice organ pieces,
+
+=item *
+
+short excerpts to be used in musicological publications.
+
+=back
=head1 NAME
-Mudela - LilyPond input format 0.1
+Mudela - GNU LilyPond input format 0.1
=head1 DESCRIPTION
-This document describes the the LilyPond input format, which is an
+This document describes the the GNU LilyPond input format, which is an
effective language for definining music. We call this language
(rather arrogantly) The Musical Definition Language (S<Mudela 0.1>).
being complete from both from a musical typesetting,
as from a musical performing point of view.
-The design of Mudela has been (perfect past tense, hopefully)
-an ongoing process,
-the most important criteria being:
-
-=over 4
-
-=item *
-
-define the (musical) message of the composer as unambiguously as possible,
-
-=item *
-
-be intuitive, and easily readable
-(compared to, say, Musi*TeX input, or MIDI :-),
-
-=item *
-
-be writable in ASCII with a simple texteditor, yfte(TM).
-
-=back
-
-Other considerations were (and will be):
-
-=over 4
-
-=item *
-
-be able to edit the layout without danger of changing the original
-music (Urtext),
-
-=item *
-
-allow for adding different interpretations, again,
-without danger of changing the original,
-
-=item *
-
-easy to create a conductor's score,
-as well as the scores for all individual instruments,
-
-=item *
-
-provide simple musical manipulations, such as
-S<(i) extracting> a slice of music from a previously defined piece,
-S<(ii) extracting> only the rhythm from a piece of music,
-S<(iii) transposing>, etc.,
-
-=item *
-
-easy to comprehend to both programmers and others.
-
-=back
-
-Musical pieces could be
-
-=over 5
-
-=item *
-
-Mahlerian orchestral scores,
-
-=item *
-
-piano pieces (Schubertian, Rachmaninovian),
-
-=item *
-
-pop songs (lyrics and chords),
-
-=item *
-
-gregorian chants,
-
-=item *
-
-Bach multivoice organ pieces,
-
-=item *
-
-short excerpts to be used in musicological publications.
-
-=back
-
=head1 Overview
Line comments are introduced by a C<%>
+=head2 Versions
+
+Occasionally, small changes in syntax across different versions of
+Mudela might give syntax errors. To warn you about possible
+incompatibilities, you can specify the Mudela version for which the
+inputfile was written,
+
+ \version "0.0.50";
+
=head2 Words
Keywords are preceded by a backslash "\". They contain alphabetic
Notenames are just a special kind of identifiers, and can be declared
for any language appropriate (see F<dutch.ini>). The default language
-for notenames is defined to be dutch,
+for notenames is defined to be dutch. In dutch, the notenames are
+a,b,c,d,e,f and g. Sharps are formed by adding the extension "is",
+flats by adding "es"
% double sharp
cisis disis eisis fisis gisis aisis bisis
-
=head2 Defaults
If omit the duration of a, a default value is substituted. For this
=head2 Music direction
-Mudela reads left to right, but LilyPond can stack voices and
+Mudela reads left to right, but you can still stack voices and
Voice_elements which are produced in two directions: horizontal
(voice like) and vertical (chord like)
its elements. The C<\multivoice> is a construct which is explained
below.
+=head2 Transposition
+
+You can transpose horizontal music in the following way:
+
+ \transpose { d % from c to d that's one octave up.
+ { e4 f4 } % the horizontal music
+ }
+
=head2 Rhythms
Rhythms in Mudela are entered identical to Simple mudela.
=head2 Examples
-Examples are included with the LilyPond distribution. For the sake of
+Examples are included with the GNU LilyPond distribution. For the sake of
maintenance no long examples are included in this document.
done by members of the same voicegroups (beams, brackets, stems)
-=head2 Other
-
-LilyPond first reads F<symbol.ini>, which contains declarations crucial
-to proper operation of LilyPond (symbol tables, note names).
=head1 HISTORY
-This language has a number of roots. First and foremost, LilyPond's
+This language has a number of roots. First and foremost, GNU LilyPond's
predecessor mpp was the inspiration of simple Mudela. Secondly, the
hierarchical structure looks a lot like Rayce's (Rayce is a raytracer
that I've written as a hobby project. ), which in turn owes a lot to
projects / lilypond.git / commitdiff