COMMENT(-*-text-*-)
-DEFINEMACRO(var)(1)(whenlatex(latexcommand({\normalfont\scshape )ARG1+latexcommand(}))\
+redef(var)(1)(whenlatex(latexcommand({\normalfont\scshape )ARG1+latexcommand(}))\
whenhtml(sc(ARG1)))
-
-
COMMENT( This document contains Mudela fragments. You need at least
Yodl-1.30.18 to convert this to tex or html.
TODO
-in stead <-> instead
+pipethrough(date) sucks.
+
+paragraphs have too much space.
+
+)
+
+COMMENT(
+ Mainly written by Han-Wen Nienhuys,
+
+ with help of (among others)
+
+ * Jan Nieuwenhuizen
+
+ * Lambert Meertens,
+
+ * Adrian Mariano
+
+ * Mats Bengtsson
+
)
htmlbodyopt(bgcolor)(white)
htmlcommand(<font color=black>)
-latexpackage()(a4wide)
latexlayoutcmds(
-%\usepackage[latin1]{inputenc}
-\input mudela-book
+ \topmargin -0.25in
+ \textheight 53\baselineskip
+ \advance\textheight by \topskip
+ \marginparwidth 1 in % Width of marginal notes.
+ \oddsidemargin 0.25 in % Note that \oddsidemargin = \evensidemargin
+ \evensidemargin 0.25 in
+ \marginparwidth 0.75 in
+ \textwidth 5.875 in % Width of text line.
+ \input mudela-book
)
whenlatex(notableofcontents())
whentexinfo(notableofcontents())
-article(Mudela, the Music-Definition Language)
+article(Mudela -- Using LilyPond to typeset music)
(Han-Wen Nienhuys and Jan Nieuwenhuizen)
(nop()PIPETHROUGH(date "+%B %d, %Y")()()nop())
-COMMENT(
-
-* paragraphs have too much space.
-
-)
-
latexcommand(\def\interexample{})
latexcommand(\def\preexample{\par})
latexcommand(\def\file#1{{code(#1)}})
whenhtml(
-nsubsect(Disclaimer)
-This document is written in url(Yodl)(ftp://pcnov095.win.tue.nl/pub/yodl)
-and should foremost produce nice LaTeX() output.
-In other formats, such as html, some things will look a bit different,
-while other things will be simply left out.
-Therefore, the authoritive version of this document is the PostScript version,
-produced via LaTeX().
+includefile(html-disclaimer.yo-urg)
)
+
sect(Introduction)
label(tutorial:introduction)
latexcommand(\parindent2pc)
-If you are reading this, you probably are interested in printing
-music. LilyPond is a program that can print music from a
-specification that you, the user, supply. Using LilyPond may be a bit
-quaint in the beginning, because you have to give that specification
-using a em(language). That might not be what you expect if you are
-familiar with graphical interfaces. But there are some big
-advantages: first, once you master the language, entering music can be
-done quite efficiently. Secondly, it is possible to explain exactly
-what the meaning of a language is, i.e., the semantics are much
-clearer. Thirdly, since the program is not interactive, no tradeoffs
-have to be made between processing speed and beauty of the output.
-
-This chapter is a gentle introduction to Mudela, the language that
-instructs LilyPond to typeset music. We will explain Mudela by
-presenting a series of examples of Mudela input. The corresponding
-output will be shown on the right or below, just as it was produced by
-LilyPond.
-
-We will assume that you more or less understand the basics of music notation.
-If you are not familiar with the English terms for music notation, you
-should consult bind(Appendix)ref(glossary): it contains a glossary
-of musical terms along with translations in some other languages.
-
-If you want to try the examples given here, you should have look a
-look at bind(Section)ref(sec:running-lilypond) first.
-
-sect(Music copying, music definition and music entry)
-label(tutorial:copying-vs-def-vs-entry)
-
-If you have copied music before, using LilyPond may seem awkward
-to you in the beginning. The purpose of LilyPond informally is
-explained by the term `music typesetter'.
-
-This may give the impression that the program is like a drawing tool
-and that it lets you control precisely how the music is formatted.
-This is not the case: not only does the program print musical symbols,
-LilyPond also tries to make esthetic decisions---to be precise, we
-programmed her to do what we find nop(pretty.)footnote(We formed our
-taste by looking at, and reading all about fine music engraving. Of
-course, our taste is also bound by all the accepted rules of common
-music notation.) You do not have complete control over what is
-happening. Usually that is not a big loss, since good engraving is a
-very complex trade. In other words, you don't have control, so you do
-not have to worry about what is happening precisely.
-
-Secondly, we expect you to enter the meaning of the music, not the
-sheet music itself. The input to LilyPond is a music definition,
-which is something different than notation: notation is a graphical
-system. Put more concretely: your input to LilyPond should contain
-information like ``a dotted quarter note, pitch nop(d)sups(2).''
-LilyPond will figure out from the musical information that a black
-note head with a stem but without flag, fourth staff line, with dot
-should be printed.
-
-When you are copying music by hand from a printed score, you don't have
-to know what the score means; you just copy the symbols. With LilyPond
-such a thing is not possible. You have to enter the meaning of the
-symbols, and this might not always be as easy. On the other hand, once
-entered, any piece of music can be played and transposed automatically.
-
-Finally, in some spots we will cheat a bit when it comes to musical
-definition. Mudela has some entry modes that help to make typing
-Mudela pleasant. For example, the phrase ``a dotted quarter note,
-pitch nop(d)sups(2)'' translates to the following longhand:
+LilyPond is a program that can print music from a specification that
+you, the user, supply. Using LilyPond may be a bit quaint in the
+beginning, because you have to give that specification using a
+em(language). This document is a gentle introduction to that
+language, which is called Mudela, an abbreviation for Music Definition
+Language.
+
+We will demonstrate the working of Mudela by presenting examples of
+input alongside with the resulting output. We will comment on these
+examples using English terms for notation, so if you are not familiar
+with these terms, you should consult the glossary that is distributed
+with LilyPond: it contains a list of musical terms along with
+explanations and translations in some other languages.
+
+sect(The first tune)
+label(sec:firsttune)
+
+To demonstrate what LilyPond input looks like, we start off with a
+full fledged, yet simple, example. It is somewhat convoluted version
+of one of the menuets in bind(J.)bind(S.)Bach's em(Clavierbuchlein).
+
+mudela(verbatim)(
+% lines preceded by a percent are comments.
+\include "paper16.ly"
+\score {
+ \notes
+ \relative c'' {
+ \key g;
+ \time 3/4;
+
+ d4 [g,8 a b c] d4 g, g |
+ e'4 [c8 d e fis] g4 g, g |
+ c4 [d8( )c b a( ] )b4 [c8 b a g] |
+ a4 [b8 a g fis] g2. |
+
+ \bar ":|";
+
+ b'4 [g8 a b g]
+ a4 [d,8 e fis d] |
+ g4 [e8 fis g d] cis4 [b8 cis] a4 |
+ [a8-. b-. cis-. d-. e-. fis-. ]
+ g4 fis e |
+ fis a, r8 cis8
+ d2.-\fermata
+ \bar "|.";
+ }
+ \paper {
+ linewidth = 14.0 \cm; % standard settings are too wide for a book
+ }
+})
+
+Before we will discuss the contents of the above, it would be best if
+you would try to enter and save this text with a text editor, compile
+it with LilyPond and view the output. Details of this procedure may
+vary from system to system. On a Unix system, you should enter the
+input in a file ending in file(.ly), such as file(menuet.ly). To
+create the output, one would issue code(ly2dvi menuet).
+
+file(ly2dvi) is a little program that does the job of calling the
+LilyPond and TeX() and adjusting page margins.
+
+If all goes well, this will create the output file file(menuet.dvi).
+To view this output, issue the command code(xdvi menuet). Now that we
+are familiar with the procedure to view the output, we will analyse
+the input itself, line by line.
+
+verb(% lines preceded by a percent are comments.)COMMENT(
+
+)The percent sign, `code(%)', introduces a line comment. If you want
+make larger comments, you can use block comments. These are delimited
+by `code(%{)' and `code(%})'
+
+verb(\input "paper16.ly")
+
+By default, LilyPond will use definitions for a staff of 20
+nop(point)footnote(A point is the standard measure of length for
+printing. One point is 1/72.27 inch.)
+
+high. If you want smaller output (e.g., 16 point), you have to import
+the settings for that size. You can do this by including a file.
+code(\include "file") is replaced by the contents of code(file).
+LilyPond will inspect the standard search to look for the requested
+file.COMMENT(
+
+)verb(\score {
+) COMMENT(
+
+) A mudela file combines music with directions for outputting that
+music. The music is combined with the output directions by putting
+them into a code(\score) block.
verb(
-\musicalpitch { 1 2 0 } \duration { 2 1 })
+ \notes
+) COMMENT(
+
+)This makes LilyPond ready for accepting notes.
+verb(
+ \relative c''
+)COMMENT(
+
+) As we will see, pitches are combinations of octave, note name and
+chromatic alteration. In this scheme, the octave is indicated by
+using raised quotes (`code(')') and ``lowered'' quotes (commas:
+`code(,)'). The central C is denoted by code(c'). The C one octave
+higher is code(c''). One and two octaves below central C is denoted
+by code(c) and code(c,) respectively.
+
+If you have to indicate the pitches in a long piece that is written in
+either a high or very low octave, you would have to type very many
+quotes. To remedy this, LilyPond has a so-called ``relative'' octave
+entry mode. In this mode, notes without quotes are chosen in such an
+octave that they are the closest to the preceding note. If you add a
+high-quote an extra octave is added. The lowered quote will substract
+an extra octave. Because the first note obviously has no predecessor,
+you have to give the (absolute) pitch of the note to start with.
+COMMENT(
+
+)verb(
+ { % sequential music follows
+)COMMENT(
+
+) The brace indicates that what follows is sequential music, i.e.,
+notes that are to be played and printed after each other. This is in
+contrast with simultaneous music: notes that are to be played like a
+chord. You should be careful not to confuse this brace with the one
+coming after code(\score).
+
+
+verb(
+ \time 3/4; % set the time signature.
+) COMMENT(
+
+) This command changes the time signature of the current piece: this
+prints a 3/4 sign. The 3/4 value is also used to generate bar lines
+in the right spots.
+verb(
+ \key g;
+) COMMENT(
+
+) This command changes the current key to G-major. Although
+this command comes after the code(\time) command, in the
+output, the key comes before the time signature: LilyPond knows about
+music typesetting conventions.
+verb(
+ d4
+) COMMENT(
+
+) This is a code(d) note. The relative music was started with a
+code(c''), the real pitch of this note is code(d''). The 4
+designates the duration of the note (it is a quarter note). COMMENT(
+
+)verb(
+ [g,8
+)COMMENT(
+
+)The open bracket starts a beam. This bracket is connected to the
+following note, which is an eighth with pitch code(g') (remember
+relative mode for pitches!)
+COMMENT(
+
+)verb(
+ a b
+)COMMENT(
+
+)These are notes with pitch code(a') and code(b'). Because their
+duration is the same as the code(g), there is no need to enter the
+duration (It is not illegal to enter it anyway. You would then enter
+code(a8 b8)) COMMENT(
+
+)verb(
+ c]
+) COMMENT(
+
+) This ends the beam started four notes earlier, at the code(g). In
+the output, you will notice a measure bar following this note. You do
+not have to enter anything to make LilyPond create a bar. Instead
+Lily will deduce where bars have to be by comparing durations of notes with
+the current time signature. COMMENT(
+
+)verb(
+ d4 g, g |
+) COMMENT(
+
+) Three more notes: The code(|) is a ``barcheck''. When processing the
+music, LilyPond will check that barchecks are found at the start of
+a bar. This can help you track down notes you forgot to enter.
+verb(
+ e'4 [c8 d e fis]
+) COMMENT(
+
+) So far, no notes were chromatically altered. Here is the first one
+that is: code(fis). Mudela by default uses Dutch note names, and
+``Fis'' is the Dutch note name for ``F sharp''. However, there is no
+sharp sign in the output. The program keeps track of key signatures,
+and will only print accidentals if they are needed.
+verb(
+ c4 [d8( )c b a( ] )b4 [c8 b a g] |
+) COMMENT(
+
+) The next line shows something new: In mudela, one enters a slur by
+marking the beginning and ending note of the slur with an opening and
+closing parenthesis respectively. In the line shown above this is
+done for two slurs. Note that parentheses (slur markers) are between
+the notes, and the brackets (beam markers) around the notes. As you
+can see, the brackets and parentheses do not have to nest.
+
+verb(
+ a4 [b8 a g fis] g2. |
+) COMMENT(
+
+) A duration that is to be augmented with a duration dot, is notated
+with a duration number followed by periods, as many as you want
+augmentation dots.COMMENT(
+
+)verb(
+ \bar ":|"; % a repeat sign
+) COMMENT(
+
+)
+Lily can not detect where you want your music to be repeated, so you
+have to instruct her: a special bar symbol can be entered by the
+code(\bar) command followed by a string that signifies the bar symbol
+that you want. Then comes a semicolon to separate the string from the
+rest of the notes, just like with code(\key) and code(\time).
+verb(
+ cis'4 [b8 cis] a4 |
+) COMMENT(
+
+) This line shows that Lily will print an accidental if that is
+needed: the first C sharp will be printed with an accidental, the
+second one without. COMMENT(
+
+)verb( [a8-. b-. cis-. d-. e-. fis-. ] % try some super and subscripts.)COMMENT(
+
+)There is more to music than just pitches and rhythms. An important
+aspect is articulation. You can enter articulation signs either in an
+abbreviated form, by a dash and the the character for the
+articulation to use, e.g. code(-.) for staccato as shown above.
+COMMENT(
+
+)verb(
+ fis a, r8 cis8
+) COMMENT(
+
+)
+Rests are denoted by the special notename code(r). You can also make
+an invisible rest by using the special notename code(s).
+verb(
+ d2.-\fermata
+) COMMENT(
+
+) All articulations have a verbose form, like code(\fermata). The
+``command'' COMMENT(Hi Adrian :-) code(\fermata) is not part of the
+core of the language (most of the other discussed elements are), but
+it is an abbreviation of a more complicated description of a fermata.
+code(\fermata) names that description and is therefore called an
+em(identifier).
+
+verb(
+ }
+) COMMENT(
+
+)
+This ends the sequential music.
+
+verb(\paper {
+ linewidth = 10.0\cm;
+})
+This specifies a conversion from music to notation output. Most of
+the details of this conversions (font sizes, dimensions, etc.) have
+been taken care of, but to fit the output in this document, it has
+to be smaller. We do this by setting the line width to 10 centimeter
+(approximately 4 inches).
+
+verb(
+ }
+)COMMENT(
+
+)The last brace ends the code(\score) block.
+
+
+
+There are a couple of things to note here. The input format tries to
+capture the meaning of em(music), and not notation. Therefore the
+format contains musical concepts like pitches and durations, instead
+of symbols and positions. Second, the format tries to be
+em(context-free): a note will sound the same regardless of the current
+time signature, the key nop(etc.)
+
+The purpose of LilyPond informally is explained by the term `music
+typesetter'. As you may have figured out by now, this is not a really
+adequate name: not only does the program print musical symbols, it
+also tries to make esthetic decisions, and it also em(generates) both
+the symbols and the decisions from a high-level musical description.
+In other words, the function of LilyPond would be best described by
+`music compiler' or `music to notation compiler'.
+
+As you can see, the most interesting part of the input is music
+itself, in this case the sequence of notes. We will therefore focus
+on entering music for now. Consequently, when we mean
+verb(\score {
+ \notes { XXXX }
+ \paper { }
+})COMMENT(
+
+) we will leave out the the repetitive details for now and just print
+code(XXXX).
-This data is what we consider the musical em(definition). Mudela
-has a special entry mode where you can conveniently abbreviate this to
-`code(d''4.)'. There are some features that also make the quotes and
-numbers in `code(d''4.)' superfluous in some cases.
-For those who are curious, the numbers in `code(\musicalpitch { 1 2 0
-})' example mean octave, notename, and accidental respectively. The
-numbers in `code(\duration { 2 1 })' are the (negative) logarithm of the
-duration (2 is a quarter note, 3 is an eighth note, etc.) and the number
-of augmention dots respectively.
sect(When you know the notes to nop(print)ellipsis())
-The basic building block of music is the note. You can have LilyPond
-print a note by specifying its pitch and duration. The pitch of the
-central C is written as code(c'). This is in line with musicological
-notation; there this pitch is transcribed as nop(c)sups(1) or c'. A
+The basic building block of music is the note. We lightly touched
+notes in the previous example. Here comes the full explanation A note
+is made of a pitch and a duration. The pitch of the central C is
+written as code(c'). This is in line with musicological notation;
+there this pitch is transcribed as nop(c)sups(1) or c'. A
quarter-note duration is written as code(4). So, to print a quarter
-note whose pitch is central C, you enter the following:
-mudela(fragment,verbatim,center)( c'4 )
-
+note whose pitch is central C, you enter the following code(c'4).
subsect(Duration)
The duration of a note is specified as a number: a whole note is
denoted by 1, a half note by 2, a quarter by 4, and so on. If you
want to augment a duration with a dot, simply affix a period to the
-number. Here are some random notes to show how it works.
+number. You can also print notes longer than a whole. You do this by
+using identifiers (code(\breve) and code(\longa)):
+Here are some random notes to show how it works.
-mudela(fragment,verbatim)(
+verb(
+ c'\longa c'\breve
c'1 c'2 c'4 c'8 c'16 c'32 c'64 c'64 c'2. c'8. c'16
)
+mudela()(
+\score {
+ \notes {
+ c'\longa c'\breve
+ c'1 c'2 c'4 c'8 c'16 c'32 c'64 c'64 c'2. c'8. c'16
+ }
+ \paper {
+ linewidth = -1.0;
+ \translator { \type "Score_engraver";
+ \name "Score";
+ \consists "Note_heads_engraver";
+ \consists "Stem_engraver";
+ \consists "Rhythmic_column_engraver";
+ }}}
+
+)
+
subsect(Basic pitches)
-The pitch code(c') actually consists of two parts: one part for the
-note name, and one for the octave. The letter specifies which note
-name to use: note names simply are the letters code(a) to code(g).
-The number of apostrophes specifies the octave to use: the central C
-is denoted by code(c').footnote(By convention, the A above central C
-at concert pitch is the tone that is used to tune instruments. Its
-frequency is about 440 Hz.) The C which is an eighth higher (the C in
-the ``two-line octave'') is denoted by code(c''): every octave adds a
+The pitch code(c') consists of two parts: one part for the note name,
+and one for the octave. The letter specifies which note name to use:
+note names simply are the letters code(a) to code(g). The number of
+apostrophes specifies the octave to use: the central C is denoted by
+code(c').footnote(By convention, the A above central C at concert
+pitch is the tone that is used to tune instruments. Its frequency is
+about 440 Hz.) The C which is an eighth higher (the C in the
+``two-line octave'') is denoted by code(c''): every octave adds a
quote. A note name without quotes designates the pitch below code(c')
(the C in the ``small octave''). If you want to go down even further,
-commas should be added, e.g., the C in the ``contra octave'' is
-expressed as code(c,,).footnote(The comma is meant to represent a
-sunken apostrophe.)
+commas (sunken apostrophes) should be added, e.g., the C in the
+``contra octave'' is expressed as code(c,,).
-
-This example demonstrates octaves:
+This example demonstrates pitches
mudela(fragment,verbatim,center)(
- c,,4 c,4 c4 c'4 c''4 c'''4
-)
-
-And this example demonstrates notenames:
-mudela(center,fragment,verbatim)(
- c'4 d'4 e'4 f'4 g'4 a'4 b'4 c''4
+ c,,4 c, c c' c'' c''' d'4 e'4 f'4 g'4
)
-A rest can be entered as a note with the special name code(r), e.g.,
-mudela(fragment,verbatim,center)(r4)
-
-This already gives us enough material to make simple songs. In
-bind(Figure)ref(fig:twinkle1) a portion of the traditional song
-``Twinkle Twinkle Little Star'' is shown.
-
-latexcommand(\begin{figure}[h])
- center(
-mudela(fragment,verbatim)(
- c''4 c''4 g''4 g''4
- a''4 a''4 g''2
-)
- latexcommand(\caption{Twinkle twinkle little star (version 1)})
- label(fig:twinkle1)
- )
-latexcommand(\end{figure})
-
subsect(Alterations)
musical vocabulary.
Enter flats and sharps. In English there is no standard terse word
-for C sharp or C flat. For this reason, we implemented a different,
+for C sharp or C flat. For this reason, mudela uses a different,
non-English convention for entering altered pitches: a note is made
sharp by adding the suffix `--is' to its name, and flat by adding the
suffix `--es'. For a double sharp another `--is' suffix is added, for
-flats another `--es' suffix. The names for the alterations of C are
-given in bind(Table)ref(notename-tab).
+flats another `--es' nop(suffix.) footnote(Variations on this
+convention are used in a number of germanic languages, notably Dutch,
+German, Swedish, and Norwegian.) The names for the alterations of C
+are given in bind(Table)ref(notename-tab).
latexcommand(\begin{table}[h])
center(
table(2)(ll)(
- row(cell(english)cell(LilyPond))
+ row(cell(English)cell(LilyPond))
rowline()
row(cell(c double flat)cell(ceses))
row(cell(c flat)cell(ces))
label(notename-tab)
latexcommand(\end{table})
-Variations on this convention are used in a number of germanic
-languages, notably Dutch, German, Swedish, and Norwegian. To be
-precise, LilyPond actually defaults to Dutch notenames, with
-code(aes), code(aeses), code(ees) and code(eeses) added for
-consistency.
-
-Throughout this document we will continue to use the Dutch names. To make
-(Dutch) pronunciation easier, the a-flat and e-flat are contracted to
-code(as) and code(es). Similarly, the a double flat and e double flat are
-contracted to code(ases) and code(eses).
+Throughout this document we will continue to use these names.footnote(
+ Mudela defaults to Dutch notenames. To make (Dutch) pronunciation
+ easier, the a-flat and e-flat are contracted to code(as) and
+ code(es). Similarly, the a double flat and e double flat are
+ contracted to code(ases) and code(eses). For consistency, the dutch
+ names also include code(aes), code(aeses), code(ees) and
+ code(eeses))
If you are not comfortable with these names, you can make your own.
Note names for different languages are included with the example
initialisation files, amongst others English (C sharp is abbreviated
to code(cs)), Italian, Swedish and Norwegian. If you want to use
-these names, you should look at bind(Section)ref(subsect:include) for
-information on how to use include files.
-
-sect(Running LilyPond)
-label(sec:running-lilypond)
-
-In the previous section some basic elements of Mudela were presented.
-We didn't want to bore you too much with repetitive details, so we
-left out some red tape that's needed for a of Mudela in a form that is accepted
-by LilyPond. To
-be precise, we wrote code(X Y Z), when we really meant
-verb(\score {
- \melodic { X Y Z }
- \paper {}
-})
-We will continue to leave out the red tape this, until the time is fit to explain what the
-above it means.
-
-
-Because LilyPond uses a language, it is a so called em(batch)
-program.
-This means, that you use a
-text editor (such as code(emacs) or code(vi)) to create an input
-file. When you are done editing your input file, you save it, and you
-run LilyPond on the file. If Lily finds any errors in your input file
-then nop(she)footnote(We're sure that if computer programs could have
- gender, LilyPond would be a female computer program. So we will
- refer to the program as a she. This gender-bending is not to tease
- you, dear reader. We do it in real life as well. In the past two
- years LilyPond has become sort of a baby daughter to us, keeping us
- awake at night, but also providing us with lots of joy. We hope you do
- not mind our little aberration from the traditions of computer-manual
- writing.) COMMENT(
- The name LilyPond is actually sort of a girl's name. Can you guess which
- one ?)
-will complain. If everything went well, then she'll generate a file, that
-you can process further to view or print.
-
-Using LilyPond to print or view some music is a four-step procedure.
-To get you started we'll run down the full procedure for you once.
-
-enumerate(
-it()
-Fire up your favourite editor (if you don't
-know any editors, try code(joe silly.ly)),
-and key in the example from bind(Figure)ref(fig:twinkle1), with red tape:
-verb(
-\score {
- \melodic {
- c''4 c''4 g''4 g''4
- a''4 a''4 g''2
- }
- \paper {}
-}
-)
-
-Save your file as file(twinkle.ly).footnote(The default extension for Mudela
-files is file(.ly).)
-
-it()
-Run LilyPond on your newly created file: enter code(lilypond twinkle).
-LilyPond will then print all kinds of mumbo jumbo that can safely be
-ignored. You might see something like this:
-verb(
-GNU LilyPond 0.1.55/FlowerLib 1.1.39
-Parsing ... [/home/hanwen/musix/spacer/init/lily-init.ly[/home/hanwen/
-
- ... stuff left out here ...
-
- ] Documentation/twinkle.ly]
-Interpreting music ...[1] (time: 0.04 seconds)
-Preprocessing elements...
-Calculating column positions ... [2]
-Approximated: 1 lines, (with an average of 4.0 columns)
-Time: 0.01 seconds
-warning: Can not solve this casting problem exactly; revert to Word_wrap
-[2]Time: 0.00 seconds
-
-Postprocessing elements...
-TeX output to twinkle.tex ...
-)
-
-All has gone well; there were some warnings but no errors. The run
-resulted in output, a TeX file called file(twinkle.tex).
-
-file(TeX) is usually spelled TeX(). It is a batch program for
-typesetting text. It was developed by the great programmer and
-scientist Donald Knuth to typeset his famous bookseries em(The Art of
-Computer Programming). As you can see, TeX() can be adapted to do a
-lot more. whenlatex(In fact, the document that you are reading now was also
-produced with TeX().) COMMENT(ugh.)
-
-
-it()
- To do something useful with the output you have to run TeX() on it
- first. Run the command code(tex twinkle). The output should resemble this:
-verb(
-This is TeX, Version 3.14159 (C version 6.1)
-(twinkle.tex
-Babel <v3.6h> and hyphenation patterns for american, dutch, loaded.
-(/home/hanwen/lib/texmf/tex/lilypond/lilyponddefs.tex
-(/home/hanwen/lib/texmf/tex/lilypond/dyndefs.tex)
-(/home/hanwen/lib/texmf/tex/lilypond/fetdefs.tex
-(/home/hanwen/lib/texmf/tex/lilypond/feta20.tex)
-(/home/hanwen/lib/texmf/tex/lilypond/lily-ps-defs.tex))) [1] )
-Output written on twinkle.dvi (1 page, 3084 bytes).
-Transcript written on twinkle.log.
-)
- The human translation is ``everything went OK, the result is one
- page long, and I put it in file(twinkle.dvi).''
-
-it()The file(twinkle.dvi) file is a description of how a piece of
-text looks when it is printed. You can view it, or print it. If you
-are using a Unix system equipped with X-Windows, then you can issue
-the command file(xdvi twinkle) to view the result. If this is not the
-case, consult your local TeX() guru on printing and viewing DVI files.
-What is in your window should approximately look like this:
-mudela()(
-\score {
- \melodic {
- c''4 c''4 g''4 g''4
- a''4 a''4 g''2
- }
- \paper { linewidth = 13.\cm; }
-}
-)
-
-it()
-If you want to print file(twinkle.dvi), you should invoke the command
-code(dvips twinkle). Running this command should generate a
-PostScript file called file(twinkle.ps). This file can be printed on
-any PostScript compatible printer. You should not use any other
-tools: the output from LilyPond contains fragments of PostScript which
-will not print correctly if you don't use PostScript. If your printer
-doesn't understand PostScript, you should check out GhostScript, a
-PostScript emulator.
-)
-
-
-
-The four-pass procedure sketched above is a bit clumsy. Moreover, the
-result is pretty crude: the page does not include prettily printed
-titles and if you are unlucky, the margins don't come out well. Jan
-Arne Fagertun wrote a tool to take the above steps out of your hands,
-make neat margins and print titling. The tool is called file(ly2dvi),
-and it should be on your system if you use Lily on a Unix platform.
-If you use file(ly2dvi), then you can do verb(ly2dvi twinkle.ly ) in
-stead of steps 2 and 3. You will feel the real advantage of using
-file(ly2dvi) when you add titling to the music. This is something
-that we will discuss in bind(Section)ref(tutorial:titling).
-
-
-COMMENT(This document does not cover all of Mudela. Due to technical details,
-the precise working of Mudela is coupled to the innards of LilyPond.
-If you really want to know all the details, your best bet would be to
-get the sources to LilyPond and read the parser and scanner source.
-They are in file(lilypond-x.y.z/lily/parser.yy) and
-file(lilypond-x.y.z/lily/lexer.ll).)
-
+these names, issue code(\include "LANGUAGE.ly") where you could
+substitute code(italiano), code(deutsch) etc. for LANGUAGE. You
+should include these files at toplevel, i.e., before opening a
+code(\score) block.
sect(Chords)
-Up till now we have only considered music that was rather simple. All
-the music had notes going in one direction, from left to right, one
-note following the other. You might be wondering if this is all Lily
-can do, or whether it is possible to stack notes as well (creating
-em(chords)). Rest assured: we designed LilyPond while keeping in mind
-that she must be able to handle any notation construct that can be
-expressed conveniently. Of course we did not leave out chords.
+The previous examples all notes that were to be played sequentially, one
+note following the other. You can also use LilyPond to typeset
+chords. You do this by expressing in mudela simultaneous music,
+i.e., notes that are to be played concurrently.
-In Mudela you can form a chord of several notes by enclosing them in
+In Mudela you can form simultaneous music by enclosing notes in
pointed parentheses, bind(i.e.)bind(langle())bind(and)rangle(). ASCII
doesn't really have these delimiters, so Mudela uses the larger-than
(code(>)) and smaller-than (code(<)) signs instead. For example, a
-D-major nop(chord)footnote(Recall what was said in the previous
-section about flats and sharps: the word code(fis) means an f sharp.)
-can be described by the following fragment:
+D-major chord is expressed as
mudela(fragment,verbatim,center)(
<d'8 fis'8 a'8 d''8>
)
- Chords can be entered in the music in the same places that notes
+Chords can be entered in the music in the same places that notes
can. As an example we give a snippet of ``Twinkle Twinkle Little
-Star'' in chords. The chords may seem, slightly unconventional, but they
-only serve to show how chords work. We've aligned the chords
-in the input on their starting beat just to help you reading it.
-This layout does not influence the typesetting result in any way.
+Star'' in chords. The chords may seem slightly unconventional, but
+they only serve to show how chords work. We've aligned the chords in
+the input on their starting beat just to help you reading it. This
+layout does not influence the typesetting result in any way.
mudela(verbatim, fragment)(
- c''4 c''4 <c''4 g''4> <c''4 e''4 g''4>
- <c''4 e''4 a''4> <b'4 d''4 a''4> <b'2 d''2 g''2>
- <a'4 d''4 f''4> <bes'4 d''4 f''4> <bes'4 c''4 e''4> <g'4 c''4 e''4>
- <e'4 a'4 d''4> <a4 g'4 cis''4> <d'2 f'2 d''2>
-)
-
-
-
-sect(Shortcuts for duration)
-
-If you typed the last example into a Mudela file, you will have
-noticed that the input has lots of repetitions. You will probably
-have made some errors with the right durations and number of
-octavation quotes.
-To save keystrokes and prevent errors Mudela
-has some handy shortcuts. The simplest is the shortcut for
-durations. You don't have to type the duration if it
-is the same as the last duration entered. This saves a considerable
-number of keystrokes, and thus reduces the potential for errors. The
-previous example can be reduced to verb(
- c''4 c'' <c'' g''> <c'' e'' g''>
- <c'' e'' a''> <b' d'' a''> <b'2 d'' g''>
- <a'4 d'' f''> <bes' d'' f''> <bes' c'' e''> <g' c'' e''>
- <e' a' d''> <a g' cis''> <d'2 f' d''>
+ \relative c' {
+ \time 2/4;
+ c4 c <c g'> <c e g>
+ <c e a> <b d a'> <b2 d g>
+ <a4 d f> <bes d f> <bes c e> <g c e>
+ <e a d> <a, g' cis'> <d2 f d'>
+ }
)
+There is one thing to note, in sequences of chords, the (relative)
+pitch of a is taken with reference to the first note of the previous
+chord.
-If you entered this, you probably made some little errors with the
-right amount of quotes as well. To remedy this, mudela has another
-feature called `relative octaves', which reduces the amount of quotes
-needed. If you want to enter large pieces of music em(now) we
-recommend you make an excursion to
-bind(Section)ref(sec:relativeoctaves) and learn about relative
-octaves.
-
-
+You can nest simultaneous and sequential music in any way you want,
+e.g., COMMENT(
-sect(Comments)
+)mudela(verbatim,fragment,center)(
+ < { g''4 g''4 }
+ { c'8 <c' e'> c' <c' e'> } >
+)COMMENT(
-If you want to make some private notes about the Mudela code that you
-entered, you can do so by inserting comments into your file. The
-contents of these comments are ignored by LilyPond. Mudela has two comment
-styles: line comments and block comments. The line comment
-is introduced by the percent sign:
-verb(
- c''4
- c''4 % shouldn't this be a different pitch?
)
+As you can see, LilyPond has some difficulty typesetting this
+elegantly. To adequately solve this, you have to persuade LilyPond to
+make separate stems for both sequential music lists. This is a topic
+that is covered in bind(Section)ref(sec:polyphonic).
-Block comments are enclosed in code(%{) and code(%}).
-
-verb(
- c''4
- %{
- Ludwig van Bavaria's original manuscript has an fffff dynamic sign.
- Clearly one can see the onset of paranoid schizophrenia in the
- composer from these subtle nuances in his writings.
- %}
- c''4
-)
+[Chords and relative mode]
sect(Adding nuances: articulation and dynamics)
-Having just chords and notes does not give you real music. Real music
-has more liveliness to it: music can have articulation, dynamics
-(louder and softer), etc. This liveliness has notation, so LilyPond
-can print it. We'll start out by explaining how to obtain the
-smallest grains of nuance: the articulation of a single note. Articulation
-is entered by writing a dash and the name of the desired articulation
-mark. You have to add a backslash in front of the name to distinguish
-it from the name of a note. mudela(fragment,verbatim)(
+Music can have articulation, dynamics (louder and softer), etc. These
+aspecs have notation, so LilyPond can print those. We'll start out by
+explaining how to obtain the smallest grains of nuance: the
+articulation of a single note. Articulation is entered by writing a
+dash and the name of the desired articulation mark. You have to add a
+backslash in front of the name to distinguish it from the name of a
+note. COMMENT(
+
+)mudela(fragment,verbatim)(
c''4-\staccato
- c''4-\tenuto )
+ c''4-\tenuto )COMMENT(
-Typing a lot of staccato notes in this syntax will get tedious very
+) Typing a lot of staccato notes in this syntax will get tedious very
quickly. Therefore, Mudela has some handy abbreviations for
articulation marks such as staccato and tenuto. They are shown in the
-following example:
-
-mudela()(
-\score{ \melodic {
- \property Voice.textstyle = typewriter
- c''4-._"c''4-." s4
- c''4--_"c''4--" s4
- c''4-+_"c''4-+" s4
- c''4-|_"c''4-|" s4
- c''4->_"c''4->" s4
- c''4-^_"c''4-\\^{ }" s4 }
- \paper { linewidth = 12.\cm; }})
-
-
-
-Text and digits for fingering can be entered in the same manner: add a
+following example: COMMENT(
+
+)mudela()(
+\score{ <
+ \property Score.textstyle = typewriter
+ \type Staff \notes {
+ c''4-.
+ c''4--
+ c''4-+
+ c''4-|
+ c''4->
+ c''4-^
+ }
+ \type Lyrics\lyrics {
+ "."4 "-" "+" "|" ">" "\^{ }" }
+ >
+ \paper { linewidth = -1.\cm; }
+})COMMENT(
+
+)Text and digits for fingering can be entered in the same manner: add a
dash and the text or digit to be printed:
-mudela(fragment,verbatim)(
- c''4-1 g''4-5 c''-"Sul tasto" )
-Currently, the meaning of the
+COMMENT(
+
+)mudela(fragment,verbatim)(c''4-1 g''4-5 c''-"Sul tasto" )
+COMMENT(Currently, the meaning of the
syntax `note-dash-digit/articulation/text' is just ``add a superscript to this
-note.'' This is not in line with our goal to em(define) music with
+note.'' This is not in line with our goal to em (define) music with
Mudela. We hope that this will be fixed in a future version of the
language. In the meantime you can abuse this: the super- and
subscripts can be forced into up or down position respectively by entering an
-a caret (code(^)) or an underscore, code(_) instead of the dash:
-mudela(fragment,verbatim,center)(
+a caret (code(^)) or an underscore, code (_) instead of the dash:
+mudela (fragment,verbatim,center) (
c'4-^ c'4^^ c'''4-^ c'''4_^
-)
+))
Dynamic markings are another way to add a nuance to a note. They are
entered by adding the name for the dynamic sign after the note. You
should not enter a dash between the name and the note.footnote(This
is inconsistent. We hope that this will be fixed in a later
- version of the language.)
-mudela(verbatim,fragment)(
+ version of the language.)COMMENT(
+
+)mudela(verbatim,fragment)(
c4 \ff c4 \fp c4 c4 \ppp c4 c4 \sfz
+)COMMENT(
+UGH
+
)
-COMMENT(UGH)
sect(Bridging the notes: beams, slurs and ties)
-Up till now most of the typesetting concerned simple fixed symbols
-only. Now we turn to variable symbols: symbols that run from one note
-to another. In LilyPond terminology, such a symbol is called a
-em(spanner). To print a spanner, you have to attach a marker to the
-note that begins it and to the one that ends it.
+Music typesetting does not use fixed symbols only. A lot of symbols
+are variable: they run from one note to another. In LilyPond
+terminology, such a symbol is called a em(spanner). To print a
+spanner, you have to attach a marker to the note that begins it and to
+the one that ends it. These are the spanners that are entered like
+this:
-
-The first example of such a symbol is the slur. For the slur, the
-start marker is the opening parenthesis. It won't be a surprise that
-the stopping marker is the closing parenthesis.
+description(
+dit(Slur)
+ The slur has the opening parenthesis as
+start marker is. The stopping marker is the closing parenthesis.
For example:
mudela(fragment,center,verbatim)( c'4( )c'4 )
-otice that the parentheses should be between the notes.footnote(The
-location of the parentheses might be changed in a future version of
-the language.)
-
-It is your job to make sure that each slur that you start also ends.
-If it doesn't end, then Bad Things are likely to happen. The slur is
-quite flexible: you can nest nop(slurs,)footnote(This is inconsistent when
-compared to the syntax for articulation hints. This will probably be
-fixed soon.) and you can connect a note with a slur on both the left and the
-right side:
+ The slur is quite flexible: you can nest nop(slurs,)footnote(This is
+inconsistent when compared to the syntax for articulation hints. This
+will be fixed some time, we hope.) and you can connect a note with a
+slur on both the left and the right side:
mudela(fragment,verbatim,center)(
c'4(( )c''4 )c'4( )g'4
)
-Another spanner is the beam (see bind(Figure)ref(mud:beam)). It
-indicates the duration of the connected notes, and thus it acts like an
-extended version of the flag. Secondly, the pattern of
-left/right-pointing beams hints at the metric structure of the
-measure.
+dit(Beam)
+The starting marker for the beam is the opening bracket, the ending
+marker is the closing bracket. The brackets have to be em(around) the
+beamed notes. footnote(Strictly speaking, a beam is not a musical
+concept: beaming doesn't change the meaning of music, it only
+clarifies the rhythmic structure. One might argue that beams should
+not be present in a music representation language. Unfortunately,
+LilyPond is not smart enough to insert beams into music on its own.
-latexcommand(\begin{figure}[h])
- center(
- mudela(fragment)([c'8 c'8] [c'16 c'16 c'16 c'16] [c'16. c'32 c'32 c'16.] )
- latexcommand(\caption{Some beams})
- label(mud:beam)
- )
-latexcommand(\end{figure})
+LilyPond does have code that guesses what the pattern should look
+like, so that you don't have to specify the beaming for complicated
+patterns. Alas, the algorithm used is not foolproof
+yet: code([c8. c32 c32]) will produce incorrect results.)
-
-Strictly speaking, a beam is not a musical concept. The pattern of a
-beam can be derived from the structure of the time signature and the durations
-of the notes. It is merely a device that helps you understand the
-rhythms notated. Unfortunately, LilyPond is not smart enough to insert
-beams into your music on her own. You will have to instruct her by
-marking the starting and stopping point of the beam with `code([)' and
-`code(])' respectively, e.g.
-
-mudela(fragment,verbatim,center)(
- [g'8 g'8]
+mudela(fragment,verbatim)(
+[c'8 c'] [c'16 c' c' c'] [c'16. c'32 c' c'16.]
)
-LilyPond has code that guesses what the pattern should look like, so
-that you don't have to specify the beaming for complicated
-patterns.footnote(Unfortunately the algorithm used is not foolproof yet:
- code([c8. c32 c32]) will produce incorrect results.)
-
-Again, it is your responsibility to make sure that you end every beam
-that you start.
-
-A third spanner is similar to the slur: the tie. The tie looks like a
-slur, but a slur connects whole chords, whereas the tie connects
-note heads. Tied notes should be played as one long note.
-In analogy with TeX()'s tie (which ties together words with a
-space), LilyPond's tie is entered as a tilde, ~.
-mudela(verbatim,center,fragment)(c''1 ~ c''4)
+dit(Tie) LilyPond's tie is entered as a tilde, `code(~)', in analogy
+ with TeX()'s tie (which ties together words with a space), The tie is
+ similar to the slur: it looks like a slur, but a slur connects whole
+ chords, whereas the tie connects note heads.
The input convention for the tilde is somewhat peculiar when used in
conjunction with chords. Internally, the extra information that is
represented by the tilde has to be attached to a note (or to a rest,
for that matter). For this reason, you can't put the tilde between
-two chords (as in code( <c' g'> ~ <c' g'>)). The tilde sign must be
+two chords (as in code(<c' g'> ~nop( )<c' g'>)). The tilde sign must be
directly after a note of the chords. It does not matter which
-one. The following example demonstrates this:
+one. The following example demonstrates the use of ties:
mudela(fragment,verbatim,center)(
- <c'1 ~ g' es''> <c'4 g' es''>
+ c''1 ~ c''4
+ <c'2. ~ g' es''> <c'4 g' es''>
+)
+
+dit(Hairpins)
+Crescendi and decrescendi can be printed in hairpin style. The
+starting marker for the crescendo is code(\<), and for the decrescendo
+code(\>). Both have code(\!) as the ending marker.
+mudela(fragment, verbatim)(
+ \relative c'' { c4 \< \! c4 \> \! c2
+ < c1
+ { s4 \< \! s4 \> \! s2 } > }
+)
+This example shows a trick: by attaching the markings to space rests
+that run parallel to the whole note, you can have dynamic markings
+within a note.
+
)
+It is your job to make sure that each spanner that you start, also
+ends. If it doesn't, then Bad Things are likely to happen. If you end
+spanners that are not started, LilyPond will warn you about illegal
+ending markers.
+
sect(Commands)
label(sec:commands)
-Up till now, we only printed notes, and correspondingly only entered
-notes. But notation contains many other constructs, constructs that
-help you with reading those notes. Examples of such constructs are
-clefs, time signatures, keys etc.
+Music notation constructs with no duration, like clefs and key
+signatures, can be entered by inserting various
+commands between the music. The general form of these commands is
+COMMENT(
-If you look carefully at the example in
-bind(Figure)ref(fig:twinkle1), you will notice that the output
-includes some bar lines and clefs, and that there are no references to
-those in the input. They were generated automatically.
+)center(code(\keyword argument argument ... ;))COMMENT(
-Not all such hints can be inserted automatically, and you can also
-override some of the settings. This can be done by inserting various
-commands between the music. The general form of these commands is
-center(
- em(keyword) sc(arguments)
-)
+)These are the commands that are currently supported in alfabetic order:
+description(
+dit(code(\bar) var(bartype))
+ This command makes LilyPond print special bar
+ lines and repeat symbols. You can also use it to allow line breaks
+ when entering cadenzas. The argument var(bartype) is a string that
+ describes what kind of bar line to print.
+COMMENT(
-em(keyword)s are words that have a special meaning to the parser of
-Mudela. Because the parser must be able to distinguish the keywords
-from note names, they have to be preceded by a so-called escape
-character, the backslash, `code(\)'. To separate the arguments from
-any notes that might follow the arguments, you have to end your
-command with a semicolon. An added benefit of this construction is
-that the commands stand out between your notes, because of the
-backslashes.
+)mudela(fragment,verbatim)(
+ \bar "|:"; c'4 \bar ":|:"; c'4 \bar ":|"; c'4 \bar "||";
+ c'4 \bar "empty"; c'4 \bar "|.";
+)COMMENT(
+
+)The command `code(\bar "empty")' does not create any visible bar
+ line, but it tells LilyPond to allow a linebreak at that position.
+ The `code(\bar)' command prints the specified symbol where you enter
+ it. If you give a `code(\bar)' command at the end of a measure then
+ the specified symbol replaces the automatic bar line.
+
+ The code(\bar) command does not affect metric structure.
-So the general form actually is `code(\keyword argument argument ... ;)'
-Let us review these commands:
+dit(code(\cadenza) var(togglevalue)) This command toggles the
+automatic printing of barlines. `code(\cadenza 1)' turns off the
+automatically generated bar lines. They are switched on again with
+`code(\cadenza 0)'. Then a bar line is printed, and LilyPond will act
+as if you are again at the start of a measure.
+
+
+This is useful when typesetting music without a meter (such as an ad
+ libitum cadenza).
-description(
dit(code(\clef) var(clefname)) This command sets the current clef for notation,
i.e., a clef symbol is printed and the notes following this command
are shifted vertically. The argument is a string, the name of the
\clef "treble"; c'4
\clef "alto"; c'4
)
-dit(code(\key) var(pitch)) This command changes the current key signature. The
- key signature is printed at the start of every line. The argument
- is the name of the corresponding major key. The key of C-minor can
- thus be specified as `code(\key es)'.
+
+dit(code(\key) var(pitch) var(type)) This command changes the current
+ key signature. The key signature is printed at the start of every
+ line. The var(type) argument is an integer. Useful values are
+ available as the predefined identifiers code(\major) and
+ code(\minor). Omitting the second argument gives major keys. The
+ key of C-minor can thus be specified as `code(\key es)' or
+ `code(\key c \minor)'.
-dit(code(\accidentals) var(pitchlist))
+dit(code(\keysignature) var(pitchlist))
-This command changes the current key signature. The signature is
-given in the form of a list of accidentals, which can be useful for
-unconventional keys. The key of C-minor can be specified as
-`code(\accidentals bes es as)'. The command `code(\accidentals fis es
-bis)' provides a more exotic example.
+This command changes the current key signature. Unlike the
+`code(\key)' command, this command can produce arbitrary key
+signatures, which can be useful for unconventional keys or modes. The
+key signature is given in the form of a list of notes. The notes will
+be printed in the key signature in the order that they appear on the
+list. For example, the key of C-minor can be specified as
+`code(\keysignature bes es as)'. The command `code(\keysignature fis
+es bis)' provides a more exotic example.
dit(code(\time) var(numerator)code(/)var(denominator))
- This command chages the current time signature. LilyPond uses the
- time signature to
- calculate where to place the bars that start a measure. These bars
- in turn are the places where a system can be broken into lines.
-
- The default value for this time signature is common time (4/4). You
- can also tell this from the Twinkle ``Twinkle Little
-Star'' example in bind(Figure)ref(fig:twinkle1). This
-song actually has a 2/4 time signature, so a metrically more correct
- version would start with as follows:
- mudela(fragment,center,verbatim)(
- \time 2/4; c'4 c' g' g'
- )
-
+ This command changes the current time signature.
+ The default value for this time signature is common time (4/4).
-dit(code(\cadenza) var(togglevalue)) When typesetting music without a
-regular meter (such as an ad libitum cadenza), no bar lines should be
-printed. In LilyPond you can achieve this by issuing the command
-`code(\cadenza 1)': it turns off the automatically
-generated bar lines.
+dit(code(\partial) var(duration))
+ This command allows you to make
+ upsteps at the start of a piece.
+ The var(duration) argument has the same form as the duration of a
+ note.
-You switch them on again with `code(\cadenza 0)', and then a bar line
-is printed. LilyPond will act as if you are again at the start of a
-measure.
-
-dit(code(\bar) var(bartype))
- This command lets you print special bar lines, such as repeats. You
- can also use it to allow line breaks when entering cadenzas. The
- argument var(bartype) is a string that describes what kind of bar line to print.
-
-mudela(fragment,verbatim)(
- \bar "|:"; c'4 \bar ":|:"; c'4 \bar ":|"; c'4 \bar "||";
- c'4 \bar "empty"; c'4 \bar "|.";
-)
- The command `code(\bar "empty")' does not create any visible bar
- line, but it does tells LilyPond to allow a linebreak
- at that position.
-
-dit(code(\partial) var(duration)) some music starts with a measure that
-isn't fully filled, a so-called upstep. The code(\partial) command
-allows you to make
-upsteps. The argument is a duration similar to the duration of a note.
+The `code(\partial)' command cannot be used to generate partial
+measures in the middle of the music.
Example:
mudela(fragment,verbatim)(
\time 4/4;
[d'8 dis'] e' c''4 e'8 c''4
)
- dit(code(\grouping) var(durationslist)) sets the metric structure of the measure.
+dit(code(\grouping) var(durationslist)) sets the metric structure of the measure.
Its effect can best be shown by an example:
- mudela(fragment,verbatim)(
+ mudela(fragment,verbatim,center)(
\time 5/16;
\grouping 16*3 16*2;
[c'8 c'16 c'8]
In practice, you won't be needing this command very often: the
grouping is switched automatically when you issue a code(\time)
-command. It is set to a combination of groups
-of 2 and 3 beats, with as many groups of
-3 as possible (in other words: 4/4 is divided in two times two beats
-(2+2), 8/8 in 3+3+2)
-)
-
-The commands that are described above aren't really music, but they
-can be used in the same places as notes. This makes the grammar of the
-language simpler. It is possible to put a command into a chord.
-For example, the following two snippets of Mudela produce identical output.
-verb(
- <c4 e g \time 2/4;>
- \time 2/4; <c4 e g>
-)
-
-
-
-sect(Complex music: more than one staff)
-label(tutorial:more-staffs)
-
-
-Now we explain how to typeset music that runs in multiple staffs.
-Consider the following---somewhat unrealistic---example:
-
-mudela(fragment)(
- \type GrandStaff <e'4 {\clef bass; g4^""} >
-)
-
- The music consists of two notes. Perhaps this is sheet music for a
-piano player, and one note is meant to be played with the left hand,
-and the other with the right hand. That music would sound the same if
-it were written as a single chord on a single staff, i.e.,
-mudela(fragment)(
- <g4 e'4>
-)
-
-
-This is another example where we can see that there can be a difference
-between a musical idea, and the way it is expressed in notation.
-
-The Mudela construct for multiple staffs reflects the similarity
-between the two examples: to get multiple staffs in Mudela you enter a
-chord, with an additional instruction to tell LilyPond that the chord
-does not represent notes stacked together, but staffs stacked
-together.
-
-If a piece of music is to be interpreted as a staff, then this can be
-expressed with the code(\type) construct. The following input says
-``the quarter note with pitch e should be put on a staff.''
-
-verb(
- \type Staff e'4
-)
-
-The same can be done for the other note, i.e.,
-
-verb(
- \type Staff g4
-)
-
-If you want to stack these staffs, you must create a chord of both:
-
-verb(
- < \type Staff e'4
- \type Staff g4
- >
-)
-
-This looks reasonable, but the effect of this input is not what you
-might expect (try it!). When interpreting this chord LilyPond will
-start with the first entry. She'll look for a (nameless) staff. Such a
-staff is not found, so it is created. On this staff the code(e) note
-is put. When the second code(\type) entry is read, LilyPond will
-start looking for a nameless staff. The staff that contains the
-code(e) is found, and the code(g) is put there as well.
-
-The correct solution is to label both code(\type) constructs with
-different names, for example code(trebleStaff) and code(bassStaff).
-This makes LilyPond distinguish between them, and create two staffs:
-
-mudela(verbatim,fragment)(
- < \type Staff = trebleStaff e'4
- \type Staff = bassStaff g4
- >
-)
-
-The names that you choose do not matter just as long as they are
-different. This is almost right, except for the brace at the left and
-the clef of the second staff. The bass clef will be taken care of in
-the next section. If you want a brace, then you have to tell LilyPond
-that the chord you just formed is to be interpreted as a so-called
-grand staff. This is also done with the code(\type) command.
-mudela(verbatim,fragment)(
- \type GrandStaff <
- \type Staff = treblestaff e'4
- \type Staff = bassstaff g4
- >
-)
-
-sect(Appending instead of stacking: sequential music)
-label(tutorial:voice)
-
-The previous section dealt with a pretty hypothetical situation: sheet
-music with two staffs and each staff containing only one single note.
-In real-life situations staffs contain more than one note. They
-contain music that has to be played in sequence. A staff can contain
-a em(voice). We haven't learned how to make a voice yet: we need a
-new construct to express this notion of `voice'.
-
-The construct is called em(sequential) music. A list of musical
-objects (e.g., notes, chords or commands) can be made into sequential
-music by enclosing the list in braces; for example:
-
-mudela(fragment,verbatim,center)(
- { c'4 c'4 }
-)
-mudela(fragment,verbatim,center)(
- { <c'4 e'> <e' g'> }
-)
-
-
-We could have called this construct more colloquially `voice', but
-this would cause confusion later on, when a second kind of voice
-enters the scene. Similar confusion might arise from the word
-`chord', therefore from now on, we will talk about `simultaneous
-music', when we refer to items enclosed in < and >.
-
-
-The notion of a em(new) construct needs some explanation: we have been
-using sequential music all the time, except that it was hidden in the
-red tape in bind(Section)ref(tutorial:introduction).
-
-
-
-If we want to put whole voices onto a staff, then we have to
-substitute sequential music for the single notes in the example from
-the previous section. A code(\clef) command in the second piece of
-sequential
-music will also set the clef in
-the bass staff.
-mudela(fragment,verbatim)(
- \type GrandStaff <
- \type Staff = treblestaff { e'4 f'}
- \type Staff = bassstaff {\clef "bass"; g a }
- >
+command. It is set to a combination of groups
+of 2 and 3 beats, with as many groups of
+3 as possible (in other words: 4/4 is divided in two times two beats
+(2+2), 8/8 in 3+3+2)
)
-COMMENT(You can nest simultaneous music and chords in any way you want. If
-you are interested in the entire story, you should consult
-bind(Chapter)ref(chap:features), which has a grammar in
-bind(Section)ref(sec:grammar).)
+The commands described above aren't really music, but they can best be
+thought as as notes with no duration. Since they are grammatically
+equivalent to notes, these commands can be used in the same places as
+notes.
sect(Notation context)
-This section is about translation contexts, a topic of LilyPond that
+COMMENT(This section is about translation contexts, a topic of LilyPond that
is somewhat advanced. You don't have to understand this to use
LilyPond to print simple music. If you don't want to typeset fancy
polyphonic music or tweak the LilyPond notation engine, you can skip
-the next two sections.
+the next two sections.)
-In bind(Section)ref(tutorial:more-staffs) it was explained, that there
+In bind(Section)ref(tutorial:more-staffs) it was explained that there
are more ways to notate a simple chord: as a single voice on a single
staff or in multiple staffs (and we'll soon see, that you can typeset
-it as multiple voices on a staff). Obviously the concept of staff is not
-really something musical. But what is it then?
+it as multiple voices on a staff). Obviously the concept of staff is
+not really something musical. But what is it then?
+The most simplistic explanation is: a staff is a graphic peculiarity
+of the notation system. In other words, a staff is a picture of five
+lines on which one can print note heads. We will call this view on
+the concept of staff `staff symbol' from now on.
-The most simplistic explanation is: a staff is a peculiarity of the
-notation system. In other words, a staff is a graphic device, a
-special picture of five lines on which one can print note heads. To
-avoid confusion, we will call this view on the concept of staff
-`staff symbol' from now on.
-
-
-There is more to it than meets the eye and mind. A staff
+But
+there is more to a staff than just the symbol. A staff
contains---besides a staff symbol--- some more components:
itemize(
-it()A staff can a have a key signature (printed at the left)
+it()A staff can have a key signature (printed at the left)
+it()A staff can have a time signature (printed at the left)
it()A staff has bar lines
it()A staff has a clef (printed at the left)
+) COMMENT(
+
)
-To explain what a staff really is, we'll try to print music without
-these components. If these components aren't printed, it is still
+To explain what a staff really is, we'll try to print music without
+these components. Without those, it is still
possible to print music:
mudela()(\score{
-\melodic \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+\notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
\paper {
linewidth = -1.;
- Staff = \translator {
- \type "Line_group_engraver_group";
-
- defaultclef = violin;
-
- \consists "Timing_engraver";
- \consists "Separating_line_group_engraver";
-
- \accepts "Voice";
+ \translator {
+ \StaffContext
+ \remove "Time_signature_engraver";
+ \remove "Bar_engraver";
+ \remove "Staff_symbol_engraver";
+ \remove "Clef_engraver";
+ \remove "Key_engraver";
}
}
-})
+})COMMENT(
-As you can see, one can still make out the general form of the melody
-and the rhythm that is to be played, but the notation is difficult to
-read and the musical information is not complete. The stress pattern
-in the notes can't be deduced from this output. For this, we need a
-time signature:
+) As you can see, you can still make out the general form of the
+melody and the rhythm that is to be played, but the notation is
+difficult to read. Moreover, the musical information is not complete.
+The stress pattern in the notes can't be deduced from this output.
+For this, we need a time signature:
mudela()(
\score {
- \melodic \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+ \notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
\paper{
linewidth = -1.;
- Staff = \translator {
- \type "Line_group_engraver_group";
- defaultclef = violin;
- \consists "Time_signature_engraver";
- \consists "Separating_line_group_engraver";
- \accepts "Voice";
- }
- }
-})
-
-Technically speaking you know where the strong and weak beats are, but
+\translator{
+ \StaffContext
+ \remove "Bar_engraver";
+ \remove "Staff_symbol_engraver";
+ \remove "Clef_engraver";
+ \remove "Key_engraver";
+ }}
+ }) COMMENT(
+
+)Technically speaking you can find out where the strong and weak beats are, but
it is difficult to find them quickly. Bar lines help you in finding
-the location within the measure of the notes:
+the location of the notes within the measure:
mudela()(
\score {
- \melodic \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+ \notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
\paper{
linewidth = -1.;
- Staff = \translator {
- \type "Line_group_engraver_group";
- defaultclef = violin;
- \consists "Bar_engraver";
- \consists "Time_signature_engraver";
- \consists "Separating_line_group_engraver";
- \accepts "Voice";
+\translator{
+ \StaffContext
+ \remove "Staff_symbol_engraver";
+ \remove "Clef_engraver";
+ \remove "Key_engraver";}
}
}
-})
+)
We can remedy part of the difficulties with reading pitches by adding a staff
symbol:
mudela()(\score{
- \melodic\relative c' { \time 2/4; g'4 c,4
+ \notes\relative c' { \time 2/4; g'4 c,4
a'4 f4 e c d2 } \paper {
linewidth = -1.;
- Staff = \translator {
- \type "Line_group_engraver_group";
-
- defaultclef = violin;
- \consists "Bar_engraver";
- \consists "Time_signature_engraver";
- \consists "Staff_sym_engraver";
- \consists "Separating_line_group_engraver";
+ \translator {
+ \StaffContext
- \accepts "Voice";
+ \remove "Clef_engraver";
+ \remove "Key_engraver";
}
}
-})
+})COMMENT(
+)
This makes the output decidedly easier to read, but you still don't
know what the pitches of the notes above are. So this is still not
enough. But suppose you see the following notation:
mudela()(\score {
- \melodic \relative c' {\clef alto; \time 2/4; g'4 c,4 a'4 f4 e c d2 }
-\paper {
- linewidth = -1.;
- Staff = \translator {
- \type "Line_group_engraver_group";
-
- defaultclef = violin;
- \consists "Bar_engraver";
- \consists "Time_signature_engraver";
- \consists "Clef_engraver";
- \consists "Staff_sym_engraver";
- \consists "Timing_engraver";
- \consists "Separating_line_group_engraver";
-
- \accepts "Voice";
+ \notes \relative c' {\clef alto; \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+ \paper {
+ linewidth = -1.;
}
- }
-})
+})COMMENT(
-Now you know the pitch of the notes: you look at the start of the line
-and see a clef, with this clef, you can determine the notated pitches.
+) Now you know the pitch of the notes: you look at the start of the line
+and see a clef, and with this clef, you can determine the notated pitches.
You have found the em(context) in which the notation is to be
interpreted!
So the context determines the relationship between a piece of music
and its notation: you, the reader, use context to deduce music from
-notation. Because LilyPond is a notation ``writer'' instead of a
-reader, context works the other way around for Lily: with context a
-piece of music can be converted to notation.
-The components of a staff form context, and context is needed to read
-and write notation. This motivates the following definition.
-
-quote(
-A bf(notation context) is a conversion from music to notation.
-)
-
-The example focused mainly on on staffs, but a staff is not the only
-type of notation context. Notation contexts may be nested: you can
-print polyphonic music by putting multiple `Voice' contexts in one
-`Staff' context. The arguments of the code(\type) command (Staff,
-GrandStaff) were in fact all names of different contexts.
-The notions of ``current clef'' and ``current position within the
-measure'' are all properties of notation contexts. Commands like
-code(\clef) and code(\cadenza) change these properties.
-
-
-The following is a list of the contexts that are supported by
-LilyPond:
+notation. Because LilyPond writes notation, context works the
+other way around for LilyPond: with context a piece of music can be
+converted to notation.
+
+We see that a staff forms context, and that context is needed to
+convert between notation and music. In LilyPond we turn around this
+reasoning: LilyPond has a notion of notation context, and the staff is
+just one example of a notation context. In fact, the arguments of the
+code(\type) command (Staff, GrandStaff) were all names of different
+contexts. A notation context is a conversion between music and
+notation.
+
+We make one final observation before listing the standard notation
+contexts: a score can contain many staffs and a staff can contain many
+voices. This suggests that notation contexts are objects that can
+contain other notation contexts.
+
+The following
+ is a list in alfabetic order of the contexts that are supported by
+LilyPond. Each notation context is characterised by its name, the
+notation elements it creates, and the contexts that it can contain.
description(
-dit(Voice) The code(Voice) context is a context that corresponds to a
- voice on a staff. This context handles the conversion of noteheads,
- dynamic signs, stems, beams, super- and subscripts, slurs, ties and rests
-
-dit(Staff) The code(Staff) context handles clefs, bar lines, keys,
- accidentals. A code(Staff) context can contain multiple code(Voice)
- contexts.
-
-dit(RhythmicStaff) The code(RhythmicStaff) context is like the staff,
- but much simpler: the notes are printed on one line, and pitches are
- ignored. code(RhythmicStaff) can contain code(Voice) contexts.
dit(GrandStaff) A code(GrandStaff) context contains code(Staff)
contexts, and it adds a brace to the output at the
- nop(left.)footnote(This is a major deficiency in the current
- implementation. Currently stems,
- slurs and beams cannot be printed across two staffs.
-In reality, a grand staff is a hybrid of one big staff and two stacked staffs.)
-
- A code(GrandStaff) context can contain multiple
- code(Staff)s. Typically, it will contain two code(Staff)s, one
- treble staff, and one bass staff. The bar lines of the contained
- staffs are connected vertically.
-
-dit(StaffGroup) A code(StaffGroup) context contains code(Staff) or
- code(Lyrics) contexts, and prints a bracket at the left. The bar
- lines in the participating staffs are connected.
+ nop(left.)footnote(The GrandStaff is quite limited, LilyPond can not
+ do cross staff beaming and slurring.)
+
+ A code(GrandStaff) context can contain code(Staff)s. Typically, it
+ will contain two code(Staff)s, one treble staff, and one bass
+ staff. The bar lines of the contained staffs are connected
+ vertically.
dit(Lyrics) As its name suggests, The code(Lyrics) context deals with
typesetting lyrics. This topic will be covered in
bind(Section)ref(tutorial:lyrics).
-dit(Score) The code(Score) context is the toplevel context: no context can
- contain a code(Score) context. The code(Score) context handles the
- administration of time signatures. It also makes sure that items
- such as clefs, time signatures, and key-signatures are aligned across staffs.
+dit(Score) The code(Score) context is the toplevel context: no context
+ can contain a code(Score) context. The code(Score) context handles
+ the administration of time signatures. It also makes sure that
+ items such as clefs, time signatures, and key-signatures are aligned
+ in columns across staffs.
+
+ The code(Score) can contain code(Staff), code(StaffGroup),
+ code(Lyrics), code(GrandStaff) and code(RhythmicStaff) contexts.
+
+dit(RhythmicStaff) The code(RhythmicStaff) context is like the staff,
+ but much simpler: the notes are printed on one line, and pitches are
+ ignored. code(RhythmicStaff) can contain code(Voice)
+ contexts.
+
+
+dit(Staff) The code(Staff) context handles clefs, bar lines, keys,
+ accidentals. A code(Staff) context can contain code(Voice)
+ contexts.
+
+dit(StaffGroup) A code(StaffGroup) context contains
+ code(Staff) or code(Lyrics) contexts, and prints a bracket at the
+ left. The bar lines in the participating staffs are connected.
+
- The code(Score) can contain code(Staff), code(StaffGroup), code(Lyrics), code(GrandStaff) and
- code(RhythmicStaff) contexts.
+dit(Voice) The code(Voice) context is a context that corresponds to a
+ voice on a staff. This context handles the conversion of noteheads,
+ dynamic signs, stems, beams, super- and subscripts, slurs, ties and rests
COMMENT(do ChoireStaff)
)
- Later on, in bind(Section)ref(tutorial:engravers) we will
-explain how you can create your own contexts.
+If you are familiar with structured documents, you might see the
+analogy of a context with a stylesheet: a stylesheet is neither
+presentation nor information, but rather a recipe em(how) a specific
+piece of information should be presented. The big difference with
+stylesheets is that in music notation the elements provided by context
+are essential to understanding what is notated.
+
+The notions of ``current clef'' and ``current position within the
+measure'' are all properties of notation contexts. Commands like
+code(\clef) and code(\cadenza) change these properties, and this
+explains why they are fundamentally different from musical expressions
+like notes and rests.
-If you are familiar with structured documents (like HTML, SGML or
-LaTeX()), you might see the analogy of a context with a stylesheet: a
-stylesheet is neither presentation nor information, but rather a
-recipe em(how) a specific piece of information should be presented.
-Analogously, a notation context is neither music nor notation, but the
-conversion between the two. The big difference with text is that in
-music notation the elements provided by context are essential to
-understanding what is notated.
+A notation context is not a primitive element of LilyPond: in
+bind(Section)ref(tutorial:engravers) it will be explained how you can
+form your own notation contexts.
+sect(Nested music: multiple staffs)
+label(tutorial:more-staffs)
+Now we explain how to typeset music that runs in multiple staffs.
+Consider the following---somewhat unrealistic---example:
-sect(Polyphonic music (or: Notation context properties))
+mudela(fragment)(
+ \type GrandStaff <e'4 {\clef bass; g4^""} >
+)
+
+In this example the music consists of two notes. The above would
+sound the same if it were written as a single chord on a single staff,
+i.e., COMMENT(
+
+)mudela(fragment)(
+ <g4 e'4>
+)COMMENT(
+
+) The Mudela construct for multiple staffs reflects the similarity
+between the two examples: to get multiple staffs in Mudela you enter a
+chord, with an additional instruction to tell LilyPond that the chord
+does not represent notes stacked together, but staffs stacked
+together.
+
+If a piece of music is to be interpreted as a staff, then this can be
+expressed with the code(\type) construct. The following input says
+``the quarter note with pitch e should be put on a staff.''
+
+verb(
+ \type Staff e'4
+)COMMENT(
+
+) The same can be done for the other note, i.e.,
-In the last section we explained that a notation context can have
-properties that influence the conversion from music to notation. A
-simple example of such a property is the clef: the type of clef partially
-determines the vertical position of note heads in a staff. Some of
-these properties can be modified by commands such as code(\clef) and
-code(\time). But there is more: notation contexts also have
-properties are settable in a generic fashion. We will demonstrate
-this feature by printing multiple voices on a staff.
-
-In polyphonic (keyboard) music and orchestral scores often more than
-one voice is printed on one staff. We'll explain how to achieve this
-effect with LilyPond. The effect is not unlike the two stacked staffs
-from bind(Section)ref(tutorial:more-staffs), except that we don't want
-to stack staffs but voices. Thus, the general template is the following:
verb(
+ \type Staff g4
+) COMMENT(
+
+) If you want to stack these staffs, you must create a chord of both:
+
+verb(
+ < \type Staff e'4
+ \type Staff g4
+ >
+)
+
+This looks reasonable, but the effect of this input is not what you
+might expect:
+mudela(fragment)(
+ < \type Staff e'4
+ \type Staff g4
+ >
+)COMMENT(
+
+) Since there are no names specified for the desired staffs, LilyPond
+thinks your wishes are fullfilled by putting the code(g) on the same
+staff as the code(e). The correct solution is to label both staffs
+with different names, for example code(trebleStaff) and
+code(bassStaff). This makes LilyPond distinguish between them, and
+create two staffs:
+
+mudela(verbatim,fragment)(
+ < \type Staff = trebleStaff e'4
+ \type Staff = bassStaff g4
+ >
+)COMMENT(
+
+) The names that you choose do not matter just as long as they are
+different. This is almost right, except for the brace at the left and
+the clef of the second staff. If you want a brace, then you have to
+tell LilyPond that the chord you just formed is to be interpreted as a
+so-called grand staff. This is also done with the code(\type)
+command. The bass clef is made with a clef command: COMMENT(
+
+) mudela(verbatim,fragment)(
+ \type GrandStaff <
+ \type Staff = treblestaff e'4
+ \type Staff = bassstaff { \clef "bass"; g4 }
+ >)COMMENT(
+
+)
+
+sect(Polyphonic music (or: Notation context properties))
+label(sec:polyphonic)
+
+In the section on notation contexts we explained that a notation
+context can have properties that influence the conversion from music
+to notation. A simple example of such a property is the clef: the
+type of a clef helps determines the vertical position of note heads in
+a staff. Some of these properties can be modified by commands such as
+code(\clef) and code(\time). But notation contexts can have other
+properties, that are settable in
+a generic fashion. We will demonstrate this feature by printing
+multiple voices on a staff.
+
+Printing more than one voice on a staff is like printing multiple
+staffs stacked together. This suggests that the template to follow is
+this:COMMENT(
+
+)verb(
\type Staff <
\type Voice = one ...
\type Voice = two ...
>
-)
+) COMMENT(
-On the ellipsis there should be music going from left to right, in
-otherr words, there should be sequential music, notes enclosed in
-braces. Let us try the following simple melodies:
+) On the ellipsis there should be music going from left to right, in
+other words, notes enclosed in braces. Let us try the following counterpoint:COMMENT(
-mudela(fragment,verbatim)(
+)mudela(fragment,verbatim)(
\type "Staff" <
\type "Voice" = "one" { r4 as'4 () as'4 g'4 }
\type "Voice" = "two" { g'2 f'4 e'4 }
As you can see the result is not quite perfect. The notes on the last
two beats look like plain chords and not like separate voices. What
really happened was that the stems of the upper and lower voices were
-printed on top of each other. If you have tried running this example, you will probably
-have noticed a complaint about ``too many
-clashing notecolumns'' during the LilyPond run.
-This complaint refers to the overlapping stems.
+printed on top of each other.
-To remedy this, engravers traditionally make the stems of the upper
-and lower voice point in different directions: the stems of the lower
+To remedy this, engravers traditionally make the stems of the lower
voice point down, and the stems of the upper up, as shown in
bind(Figure)ref(tutorial:multi-voice-fig).
Surely the direction of a single stem is a property of the stem as a
graphical object. But the fact that all of the stems in a voice point
in the same direction is not directly graphical. Since this is a
-property shared by all the stems in the voice, it is logical to
-consider this property to be a property of the context code(Voice).
-And this is how it's done in LilyPond: the context code(Voice) has an
-attribute whose value is the direction to use
-for stems. You can change it to `up'
-by issuing the following phrase:footnote(The name code(ydirection) is
-no mistake. The property also controls the up/down directions of
-super-/subscripts, slurs, ties, etc.)
-
+property shared by all the stems in the voice, this property is a
+property of the context code(Voice). The context code(Voice) has an
+attribute whose value is the direction to use for stems. You can
+change it to `up' by issuing the following phrase:
verb(
\property "Voice"."ydirection" = "1"
)
This command should be read as ``change the property called
code(ydirection) within the current code(Voice) context to the value
code(-1).'' For the property code(ydirection) the value code(1) means
-`up', and code(-1) means `down'. The proper way to code the
-polyphonic example is given in bind(Figure)ref(tutorial:multi-voice-fig).
+`up', and code(-1) means `down'. So, the
+proper way to code the polyphonic example is given in
+bind(Figure)ref(tutorial:multi-voice-fig).
latexcommand(\begin{figure}[h])
mudela(fragment,verbatim,center)(
g'2 f'4 e'4 }
>
)
- latexcommand(\caption{multiple voices})
+ latexcommand(\caption{Multiple voices})
label(tutorial:multi-voice-fig)
latexcommand(\end{figure})
+As you can see, this property also controls the directions of slurs.
+
Other properties can also be set, and they can be within different
contexts. In general, you can set a property by specifying
code(\property) var(contexttype)code(.)var(propertyname) code(=)
-var(value). Both var(ContextType), var(PropertyName) and var(Value)
+var(value). Both var(contexttype), var(propertyname) and var(value)
should be strings.
The effect of a property is pretty much hardwired into the
implementation (and thus subject to change), so we will not deal with
-all the possible properties in detail. Among other characteristics that
-can be set are the layout of slurs and beams. The initialisation file
-file(property.ly) explains most properties.
-
-We conclude this section with another example of a context property.
-Polyphonic music that has three or four voices can't be printed by
-simply changing the directions of the stems for each voice, obviously.
-Traditionally, some chords are shifted horizontally to print if this many
-voices have to be printed.
-LilyPond can also do this, and the property that controls the
-horizontal shifting is called code(hshift). The notes in a
-code(Voice) context that has code(hshift) set to a true value (i.e.,
-non-zero or non-empty), will be shifted horizontally in the case of a
-collision. The following example demonstrates the effect.
-
-mudela(fragment,verbatim)(
- \type "Staff" <
- \type "Voice" = "one" {
- \property Voice.ydirection = "1"
- r4 as'4 () as'4 g'4 }
- \type "Voice" = "two" {
- \property Voice.ydirection = "1"
- \property Voice.hshift = 1
- g'2 f'4 e'4 }
- \type "Voice" = "three" {
- \property Voice.ydirection = "-1"
- [d'8 dis'] [d' cis'] [c' b] c'4
- }
- >
-)
+all the possible properties in detail. Among other characteristics
+that can be set are the layout of slurs and beams. The initialisation
+file file(property.ly) and the reference manual contain explanations
+of all properties.
sect(Lyrics)
label(tutorial:lyrics)
-Now for something completely different: Lyrics. Lyrics are also
-considered to be music, although a lyric by itself does not have any
-pitch. Producing lyrics has two aspects. First, you have to enter the
-text, i.e., the syllables along with their durations.
-After this, you have to specify how to convert these to graphics.
+Since a lyrics can have durations just like notes, we consider them to
+be music too. Entering lyrics in mudela has two aspects. First, you
+have to enter the text, i.e., the syllables along with their
+durations. After this, you have to specify how to convert these to
+graphics.
Lyrics consist of syllables, which are strings together with
-durations. Previously we only entered note names, so for entering
-lyrics we have to instruct LilyPond that what we enter are not note
-names but words---or rather: strings. This instruction is the keyword
-code(\lyric). After entering this keyword you can enter a musical
-construct---sequential music, simultaneous music, code(\type)
-entries, etc.--- but with syllables in stead of pitches. For example:
-verb( \lyric { 'got8 me on my knees4, Le-8 lie! })
-
-The effect of code(\lyric) can be compared with the effect of the
-doublequote character, code("), for it also changes the lexical
-meaning of spaces and characters. This mode is another example of a
-handy input feature of the language.
-
-Next comes the conversion to notation. LilyPond can't (yet) figure
+durations. For entering lyrics we have to instruct LilyPond that what
+we enter are not note names but strings. This instruction is the
+keyword code(\lyrics). After entering this keyword you can enter a
+musical construct---sequential music, simultaneous music, code(\type)
+entries, etc.--- but with syllables instead of pitches. For example:
+COMMENT(
+
+)verb(\lyrics { 'got8 me on my knees4, Le-8 lie! })COMMENT(
+
+) Next comes the conversion to notation. LilyPond can't (yet) figure
out that lyrics need different treatment than notes. As a result, the
default conversion will try to put the text you entered as note heads
-onto a staff, and this will fail. This default must be overriden with
-a code(\type) keyword. Printing syllables of text in a line is done
-by a context called code(Lyrics). You can select this context with
-the code(\type) keyword. Here is a simple example:
+onto a staff, and this will fail. This default must be overridden
+with a code(\type) keyword. Printing syllables of text in a line is
+done by a context called code(Lyrics). You can select this context
+with the code(\type) keyword. Here is a simple example with output:
+COMMENT(
-mudela(fragment,verbatim)(
- \type Lyrics \lyric { 'got8 me on my knees,4 Le-8 lie! })
+)mudela(fragment,verbatim)(
+\type Lyrics \lyrics { 'got8 me on my knees,4 Le-8 lie! })COMMENT(
-The result is technically more or less correct, but without a melody it
-just doesn't work, so let's add a blob of cream:
-mudela(fragment,verbatim)(
+)The result is technically correct, but it needs a melody to make it
+performable: COMMENT(
+
+)mudela(fragment,verbatim)(
<
\type Staff { c''8. c''16 bes'8. a'16 g'4 f'8 g'4. }
- \type Lyrics \lyric { 'got8. me16 on8. my16 knees,4 Le-8 lie!4. }
+ \type Lyrics \lyrics { 'got8. me16 on8. my16 knees,4 Le-8 lie!4. }
>
-)
-
-The strings that makes up each syllable in the lyrics block are passed
-along to TeX() verbatim, so if you are proficient with TeX() you can
-do various nifty things. Just keep in mind that a syllable either
-starts with a letter (a character in the range `code(a)' to `code(z)'
-or `code(A)' to `code(Z)'), or it is a string enclosed quotes. It ends
-with either a number for the duration, or a space. A last feature
-that should be mentioned is the space-lyric: if you want to enter
-a single ``syllable'' that consists of multiple words, i.e., words
-separated by spaces, you should use an
-underscore instead of a space. All these tricks are demonstrated in
-the following example:
+) COMMENT(
+
+) The strings that makes up each syllable in the lyrics block are
+passed along to TeX() verbatim, so if you are proficient with TeX()
+you can do various nifty things. Just keep in mind that a syllable
+either starts with a letter (a character in the range `code(a)' to
+`code(z)' or `code(A)' to `code(Z)'), or it is a string enclosed
+double quotes. It ends with either a number for the duration, or a space.
+These tricks are demonstrated in the following example:
+COMMENT(
-COMMENT( urg
-\type Lyrics \lyric { 'got_m\textbf{e}4 on8. m$\cal_Y$16 knees,4 Le-8 lie!4.}
-\type Lyrics \lyric { 'got_m{\bf e}4 on8. m$\cal_Y$16 knees,4 Le-8 lie!4.}
-)
+urg
+\type Lyrics \lyrics { 'got8 m\textbf{e}8 on8. m$\cal_Y$16 knees,4 Le-8 lie!4.}
+\type Lyrics \lyrics { 'got8 m{\bf e}4 on8. m$\cal_Y$16 knees,4 Le-8 lie!4.}
+)COMMENT(
-mudela(fragment,verbatim)(<
+)mudela(fragment,verbatim)(<
\type Staff { c''8. c''16 bes'8. a'16 g'4 f'8 g'4. }
- \type Lyrics \lyric { 'got_me4 on8. m$\cal_Y$16 "3s,"4 Le-8 lie!4.}
+ \type Lyrics \lyrics { 'got8 me8 on8. m$\cal_Y$16 "3s,"4 Le-8 lie!4.}
>
-)
-
-The spacing in the above example is a bit skewed because Lily can't
-tell that the long syllables you entered are not ordinary characters,
-but expand to really small symbols.
+)COMMENT(
-
-
-COMMENT(Rood is de kleur van geluk.)
-COMMENT(Dat geldt ook voor haar.)
-
+) COMMENT(Groen is de kleur van geluk. Dat geldt zeker voor Bj"ork)
sect(Toplevel Mudela)
-Now the time has come to unravel the red tape that we have hidden from
-you in the introduction. Mudela has a hierarchical structure for we
-have seen that sequential and simultaneous music can be nested.
-Mudela also has other `blocks' that can be nested. The general syntax
-for a block is code(\keyword { ... }).
-
-When you run LilyPond, what happens is that you define music, and
-specify one (or more) conversions to apply to that music, for example
-a conversion to notation. This is done by putting the definition of
-the music and the definition of the conversion together in a
-code(\score) block, e.g.,
-verb(
-\score {
- % ... music ...
- \paper {}
-})
+Back in bind(Section)ref(sec:firsttune) we said we would ignore
+toplevel constructions (e.g., code(\score)) until some later moment.
+Now we will look at these constructions.
-This is almost the context that should be around all
-of the previous examples. The precise context reads thus:
-verb(
-\score {
- \melodic { ... }
- \paper {}
-})
-On the ellipsis, you entered what shown as the example input.
-You can see that in the
-above example, the code(\melodic { ... }) forms the music, the
-code(\paper {}) is a conversion to paper (notation, that is). The
-code(\paper) definition is copied from a default definition
-(which is in the initialisation file file(paper16.ly)).
-The paper part also contains
-the definition of the contexts.
-
-The keyword code(\melodic) is analogous to the code(\lyric) keyword. It
-will switch the tokenizer into a mode that interprets plain words as
-note names. If it can't recognize the words as a note name, it will
-assume that they are strings. That is the reason why you can write
-code(\clef bass) in stead of code(\clef "bass"); most of the strings
-in code(\melodic) mode can be written without quotes.
-
-The braces that you see after the code(\melodic) keyword are the
-braces that are around sequential music. Because of these braces, the
-sequences of notes in our simple examples were sequential (and not
-simultaneous). As a result the notes were printed from left to right,
-and not stacked.
-
-sect(Identifiers)
-
-
-Now that we are comfortable with the toplevel entries in a mudela
-file, we can investigate some more of the recreations on toplevel, in
-particular em(identifiers). Generally you can define an identifier by
-entering code(identifierName = ... )
-where there can be a variety of things on the ellipsis.
+Mudela allows you to name constructs of the language. This is done by
+using an em(identifier). Generally you can define an
+identifier by entering code(identifierName = ... ) where there can be
+a variety of things on the ellipsis.
+COMMENT(
Here is a (partial) list of what you can abbreviate with identifiers
at top-level.
itemize(
it()Integers
it()Reals
)
+)
When you refer
to the abbreviated entity, you must precede code(identifierName)
with a backslash, i.e., code(\identifierName). For example:
mudela(verbatim)(
- czerny = \melodic { [c16 g e g] }
+ czerny = \notes { [c16 g e g] }
\score {
- \melodic \type GrandStaff <
+ \notes \type GrandStaff <
{ c''2 g''2 }
{ \clef bass; \czerny \czerny \czerny \czerny}
>
\paper {
linewidth = -1.0;
- stem_length = 12.0*\internote;
}
}
)
-
-
-Another interesting feature of this example are the assignments within
-the paper block. Some blocks, such as code(\paper), have a scope of
-their own. In the case of the code(\paper) block, these variables
-influence the characteristics of the output. As is shown, you can
-tune quantities like the stemlength, and enter simple expressions.
-The purpose of the negative linewidth is to prevent the music from
-being justified. The identifiers that are meaningful are for the
-paper block is strongly implementation dependent, so they will not be
-listed here. Moreover, since most of the values are predefined to
-sensible defaults, there usually is no need to tune these values.
+You can also see identifiers in action within the code(\paper) block:
+the value code(-1.0) is assigned to code(linewidth). Within the
+code(\paper) block, identifiers are not used as abbreviation only:
+assigning to some identifiers can influence the output: in this case,
+the music line is printed at natural width.
Recall the properties of a context, that could be set with
code(\property). It is a very general mechanism to tune the output of
stemdown = \property Voice.ydirection = "-1"
shift = \property Voice.hshift = "1"
\score {
- \type "Staff" \melodic <
- \type "Voice" = "one" {
- \stemup
- r4 as'4 () as'4 g'4 }
- \type "Voice" = "two" {
- \stemup
- \shift
- g'2 f'4 e'4 }
- \type "Voice" = "three" {
- \stemdown
- [d'8 dis'] [d' cis'] [c' b] c'4
- }
- >
+ \type "Staff" \notes <
+ \type "Voice" = "one" { \stemup r4 as'4 () as'4 g'4 }
+ \type "Voice" = "two" { \stemup \shift g'2 f'4 e'4 }
+ \type "Voice" = "three" { \stemdown [d'8 dis'] [d' cis'] [c' b] c'4 } >
\paper{ linewidth = -1.0\pt; }
-}
-)
+})
-Several abbreviations like code(\stemup) are defined in the
-standard initialisation file file(property.ly). Setting or changing
-context properties can have a similar effect as the commands that were
+Several abbreviations like code(\stemup) are defined in the standard
+initialisation file file(property.ly). Setting or changing context
+properties can have a similar effect as the commands that were
discussed in bind(Section)ref(sec:commands). Don't be fooled by the
-similarity in appearance between a declared property-setting entry
-and a real command. Real commands are hardcoded into the language
-and they have to be terminated by semicolons.
-
-You can also use identifiers to break up the heavy nesting that can occur
-in the code(\score) block. Another useful application is
-parametrisation of the music: if you use identifiers in the
-code(\score) block, you can make variations of the music by simply
-redefining those identifiers. One particular application of this is
-part extraction: by using identifiers and redefining them, one can
-print extracted parts and a full orchestral score from the same
-music definition.
-
+similarity in appearance between a declared property-setting entry and
+a real command like code(\clef) or code(\bar). Real commands are
+hardcoded into the language and they have to be terminated by
+semicolons.
sect(Sound output)
label(tutorial:sound)
You get output by combining music with definition a conversion to
-output. Up till now we have only focused on the graphic output of
-traditional engraving. But there is no reason why that should be the
-only form of output for music. LilyPond currently supports one other
-conversion: the conversion from abstract music to sound. You can have
-LilyPond play the music that you entered. The format that is used
-for this output is MIDI.
+output. LilyPond currently supports one other conversion besides
+notation: the conversion from abstract music to sound. You can have
+LilyPond play the music that you entered. The format that is used for
+this output is MIDI. The result is not very pretty, but it is useful
+for prooflistening your files: typing errors stand out when you
+listen, especially if they involve accidentals.
The only information that you need to enter is the
- nop(tempo)footnote(Unfortunately,
-this the only thing that can be tuned at this
-time. This is a limitation: the tempo of music can vary throughout
-the music.) for the performance. The syntax for the tempo is
-code(\tempo )var(duration) = var(beatsperminute);), for example:
-verb(
+tempo (Unfortunately, at this time, this the only thing that can be
+tuned.). The syntax for the tempo is code(\tempo )var(duration) =
+var(beatsperminute);), for example: COMMENT(
+
+
+)verb(
\score {
...music...
\midi { \tempo 4 = 76; }
-}
-)
-
-The most useful purpose of this sound output is to prooflisten your
-files: typing errors (especially if they involve accidentals) stand
-out when you listen.
-The output was implemented in a very rudimentary manner, so it is
-probably not worth listening to for any other reason.
+}) COMMENT(
+)
sect(Contexts revisited: engravers)
label(tutorial:engravers)
of LilyPond: redefining (notation) contexts. We previously explained
that a context
itemize(
+it()has a name
it()is a conversion from music to notation,
it()can contain other contexts
it()handles specific notation constructs
This characterization almost automatically explains what the definition of a
context should look like:
itemize(
+it() It should define a name
it()It should be part of the ``notation output definition,'' i.e., the
code(\paper) block
it()
handled.
)
-In practice, the context definition
-looks like this:
-verb(
-\translator
-{
- \type "Engraver_group_engraver";
- \accepts "...";
- \accepts "...";
- \accepts "...";
-
- \consists " ... ";
- \consists " ... ";
- \consists " ... ";
+LilyPond can create notation for a large number of symbols. This code
+is split up into basic building blocks. Each building block is called
+an em(engraver), and an engraver generally handles only one notation
+construct: the code(Clef_engraver) takes care of the clefs, the
+code(Time_signature_engraver) takes care of printing time signatures,
+etc.
- propertyname = "value";
- propertyname = "value";
+A notation context is formed by a group of engravers. A special class
+in LilyPond---the code(Engraver_group_engraver)---allows engravers to
+cooperate in a group, thus forming a notation context. A variant of
+this grouping object is the code(Line_group_engraver_group), which
+puts the output of all the engravers (clefs, bars, etc) into a
+compound object, so that these symbols can be treated as a whole.
-} )
+The following definition shows a simplified Staff context: COMMENT(
- This is encoded by the
+)verb(
+\translator
+{
+ \type "Line_group_engraver_group";
+ \name Staff ;
-The code(\translator) keyword opens the block for translation (or
-context) definition. The code(\type) keyword explains to Lily that
-the context should be formed by taking an (empty) instance of
-code(Engraver_group_engraver). The code(Engraver_group_engraver) is a
-C++ class from the source code to Lily. The code(\accepts) entries
-explain what kind of contexts this context could contain. If we were
-to define a context for a staff, the definition would typically
-contain code(\accepts "Voice";).
+ \consists "Bar_engraver";
+ \consists "Clef_engraver";
+ \consists "Key_engraver";
+ \consists "Local_key_engraver";
+ \consists "Time_signature_engraver";
+ \consists "Staff_symbol_engraver";
-The code(\consists) entries specify which notation constructs should
-be handled. This needs a little explanation: LilyPond contains the
-code for quite a large number of basic building blocks for notation
-generation, and each building block handles only one notation
-construct. The name of such a building block is `engraver'. You can
-specify which notation construct a context should handle by specifying
-which engravers should be part of the context. The code(\consists
-"Foobar") entry really means ``add an instance of code(Foobar) to the
-translation group.''
+ defaultClef = treble;
+
+ \accepts "Voice";
+}) COMMENT(
+) This context, named Staff, puts its graphic objects into a compound
+object (a so-called ``Line group''). At Staff level, bars, clefs,
+keys, accidentals, time signatures and the staff symbol are handled.
+A staff can contain a Voice context. You can also preset properties
+of contexts: for instance, the clef that is printed upon starting a
+Staff, is the treble clef.
-For example if this context should print time signatures, the definition
-should include `code(\consists "Time_signature_engraver";)'. Again
-code(Time_signature_engraver) is a class from the source code of LilyPond.
+As a practical example, we will show how to typeset polymetric music,
+i.e., music where the meter can differ for each staff. The solution
+is not very complicated: normally all timing information (time
+signature, rhythmic grouping) is synchronised across each staff. This
+is done by having only one administration for timing information: in
+the default configuration there is only one code(Timing_engraver), in
+the code(Score) context.
-Finally, one can pre-set some properties in a context definition.
+All staffs use the information in the code(Timing_engraver) for
+generating bar lines and time signatures. So, we can have different
+timing for every staff, by moving the code(Timing_engraver) into the
+ Staff context.
-As a practical example, we will show you how to typeset polymetric
-music, i.e., music where the meter can differ for each staff. The
-solution is not very complicated: normally all timing information
-(time signature, rhythmic grouping) is synchronised across each staff. In
-LilyPond this is expressed by having only one registration for timing
-information for all staffs. To be precise, there is only one
-code(Timing_engraver), and it is located in the top level context, the
-code(Score) context.
+You can also declare contexts, and reference them. This is useful in
+combination with code(\remove "..."): code(\remove) does the opposite
+of code(\consists).
-All staffs use the information in the global code(Timing_engraver)
-for generating bar lines and time signatures. In polymetric music, this timing
-information can be different for every staff, so we should redefine
-the code(Staff) context to include and the code(Score) context to exclude the
-code(Timing_engraver).
mudela(verbatim)(
-polymetricpaper = \paper {
- Score = \translator {
- \type Score_engraver;
- \consists "Score_priority_engraver";
- \consists "Priority_horizontal_align_engraver";
- \consists "Vertical_align_engraver";
- % \consists "Timing_engraver"; % removed Timing_engraver
- \accepts "Staff";
- }
-
- Staff = \translator {
- \type "Line_group_engraver_group";
-
- defaultclef = violin;
-
- \consists "Bar_engraver";
- \consists "Clef_engraver";
- \consists "Key_engraver";
- \consists "Local_key_engraver";
- \consists "Time_signature_engraver";
- \consists "Timing_engraver"; % added Timing_engraver
- \consists "Staff_sym_engraver";
- \consists "Separating_line_group_engraver";
-
- \accepts "Voice";
- }
-}
-\score {
- \melodic <
- \type Staff = one { \time 2/4; c'4 c'4 c'4 c'4 c'4 c'4 }
- \type Staff = two { \time 3/4; c'4 c'4 c'4 c'4 c'4 c'4 }
- >
- \paper { \polymetricpaper
- linewidth = -1.;
+ \score {
+ \notes <
+ \type Staff = one { \time 2/4; c'4 c'4 c'4 c'4 c'4 c'4 }
+ \type Staff = two { \time 3/4; c'4 c'4 c'4 c'4 c'4 c'4 }
+ >
+ \paper {
+ linewidth = -1.;
+ \translator {
+ \ScoreContext
+ \remove "Timing_engraver";
+ }
+ \translator {
+ \StaffContext
+ \consists "Timing_engraver";
+ }
}
}
)
-As you can see, we used the identifier code(polymetricpaper) to break
-up the large score block. More of these context definitions appear in
-the standard initialisation file file(engraver.ly).
+The context definitions provided as a default are in the standard
+initialisation file file(engraver.ly).
+
sect(Urtexts and context selection)
label(tutorial:urtext)
-In bind(Section)ref(tutorial:more-staffs), we have shown you how to make
-multiple staffs, and explained that you have to label every staff (or
-more precisely: different contexts), to make sure that new ones are
-created when you need them. In this section, the real power of this
-mechanism will unveiled.
+In bind(Section)ref(tutorial:more-staffs), we have shown you how to
+make multiple staffs, and explained that you have to label every staff
+(or more precisely: different contexts), to make sure that new ones
+are created when you need them. In this section, the real power of
+this mechanism will be unveiled.
-By naming other contexts that you create, you can reference other contexts
-than the current context from within the music. For example, from within the music that you
-enter for staff code(One), one could enter a small piece of music,
-and send it to staff code(Two), e.g.,
-mudela(fragment,verbatim)(
+By naming other contexts that you create, you can reference other
+contexts than the current context from within the music. For example,
+from within the music that you enter for staff code(One), one could
+enter a small piece of music, and send it to staff code(Two), e.g.,
+COMMENT(
+
+) mudela(fragment,verbatim)(
<
\type Staff = one { c''4 \type Staff = two { c4 c4 } c''4 }
\type Staff = two { \clef bass; g,4 g,4 g,4 g,4 }
)
-Another useful application of this feature is making Urtexts.
-em(Urtext) is the German word for `original text'. The Urtext
-edition of a piece of music, is an edition that reflects the original
-writing of the composer. Such editions are useful for musicologists,
-and performers that want to perform authentic interpretations. However,
-for mere mortals, the Urtext can be quite hard to read. It might not
-contain fingering and beaming, and typically it is full of footnotes.
-Moreover, common interpretations may have emerged---after the composer
-died. For this reason, the music that can be had as Urtext usually is also
-available in enhanced and edited editions.
-
-The mechanism of context selection can be used to fabricate an Urtext
-and an edited edition from em(one source). We will use the first few
-bars of bind(J.)bind(S.)Bach's lovely Cello suite bind(no.)I to
-demonstrate this. The example makes heavy use of space rests: a space
-rest is a like a rest that doesn't print anything. It can be used as
-a placeholder, to attach articulation marks to. It is entered as a
-note with the name code(s).
+
+The mechanism of context selection can be used to fabricate an
+nop(Urtext)footnote(em(Urtext) is the German word for `original text'.
+The Urtext edition of a piece of music, is an edition that reflects
+the original writing of the composer. Such editions are useful for
+musicologists, and performers that want to perform authentic
+interpretations. However, for mere mortals, the Urtext can be quite
+hard to read. It might not contain fingering and beaming, and
+typically it is full of footnotes. Moreover, common interpretations
+may have emerged---after the composer died. For this reason, the
+music that can be had as Urtext usually is also available in enhanced
+and edited editions. ) and an edited edition from em(one source). We
+will use the first few bars of bind(J.)bind(S.)Bach's first Cello
+suite to demonstrate this. The example makes heavy use of space
+rests; here they are used as a placeholder to attach articulation
+marks to.
mudela(verbatim)(
- bach = \melodic { [c16 g e' d'] [e' g e' g] }
+ bach = \notes \relative c { [g16 d' b' a] [b d, b' d,] }
- staffStuff = \melodic { \clef bass; \time 4/4; s1 \bar "|."; }
+ staffStuff = \notes { \clef bass; \time 4/4; s1 \bar "|."; }
- slursOne = \melodic { s16( s s s s16 s s )s }
- slursTwo = \melodic { s16-. s s() s s16() s s ()s }
+ slursOne = \notes { s16( s s s s16 s s )s }
+ slursTwo = \notes { s16-. s s() s s16() s s ()s }
\score{
{ < \type Voice = celloVoice { \bach \bach }
\staffStuff
>
}
- \paper {}
+ \paper { linewidth = -1.;}
}
)
- The slurs that you define should be put on the music that is defined
+The slurs that you define should be put on the music that is defined
by the code(\bach) identifier. By labeling a code(Voice) context, and
directing both the articulation and the notes to that same code(Voice)
context, the articulation is put over the right notes.
sect(Transposing)
label(tutorial:more-grammar)
-COMMENT(In this section, we will complete the grammar for Music that was
-sketched earlier. )
-One of the things that you can do with music is
-em(transposing) it. If you want to transpose a piece of music, then
-you should prefix the keyword code(\transpose) along with the pitch
-(relative to the central C) for the transposition.footnote(the
+
+One of the things that you can do with music is em(transposing) it.
+If you want to transpose a piece of music, then you should prefix it
+with the keyword code(\transpose) along with the pitch (relative to
+the central C, i.e., code(c')) for the transposition.footnote(the
code(\type Staff) is to make sure that no separate staffs are created
for the code(\scale) and code(\transpose cis' \scale) part.)
mudela(verbatim)(
-scale = \melodic \relative c' { [c8 d e f] }
+scale = \notes \relative c' { [c8 d e f] }
\score {
- \melodic {
+ \notes {
\type Staff { \scale \transpose cis' \scale }
}
\paper { linewidth = -1.0; }
mudela(verbatim)(
% real music
-aVoice = \type Voice = voiceA \melodic { c''4 c4 c4 c''4 }
-bVoice = \type Voice = voiceB \melodic { g,4 g,4 g,4 g,4 }
+aVoice = \type Voice = voiceA \notes { c''4 c4 c4 c''4 }
+bVoice = \type Voice = voiceB \notes { g,4 g,4 g,4 g,4 }
% staff switching stuff
-switch = \type Voice = voiceA \melodic { s4 \translator Staff = staffB s4
+switch = \type Voice = voiceA \notes { s4 \translator Staff = staffB s4
s4 \translator Staff = staffA s4 }
\score {
)
Don't try to switch staffs when you are in the middle of a slur or
-beam, though. It doesn't work yet.
-
-sect(Hairy durations: triplets)
-
-In the previous section we explained an operation that changes the
-pitches of music, transposition. In this section we will explain an
-operation that modifies the duration of the notes that you enter.
-When notes are part of a triplet, then the real of duration of the
-notes are 2/3 part of what their shape indicates:
-mudela(fragment)(
-\[/3 c'4 c'4 c'4 \]/1
-)
-
-To support this notion, Mudela allows you to modify the duration of a
-note by multiplication or division. A code(c'4) note that would be in a
-triplet is written as code(c'4*2/3). If you sequence a few of these
-notes, you get a triplet.footnote(We added a normal staff in the example to
-show the difference.)
-mudela(fragment,verbatim)(
-< \type Staff = staffA { c'8*2/3 c'8*2/3 c'8*2/3 c'4}
- \type Staff = staffB { c''8 c''8 c''4 } >)
-
-LilyPond knows that these notes are no normal eighth notes, but the
-reader doesn't yet. To help the reader a beam or a bracket with a `3'
-should be printed. The special beam command `code([2/3)' and the
-matching close beam `code(]1/1)' will take care of that, and
-they also abbreviate the code(*2/3) part. If you want brackets in
-stead of beams, you can use `code(\[2/3])' and `code(\]1/1)'.
-mudela(fragment,verbatim)(
-< \type Staff = staffA {
- [2/3 c'8 c'8 c'8 ]1/1
- \[2/3 c'8 c'8 c'8 \]1/1
- }
- \type Staff = staffB { [c''8 c''8 c''8 c''8] }
->)
-
-Other tuplets can be entered in the same way.
-mudela(fragment,verbatim)(
-< \type Staff = staffA {
- \time 7/8;
- [7/6 c'8 c'8 c'8 c'8 c'8 c'8 ]1/1
- }
- \type Staff = staffB {
- \time 7/8;
- [c''8 c''8 c''8 c''8 c''8 c''8 c''8] } >
-)
-
-For your convenience, code([2/3) can be further abbreviated to code([/3), and
-you can abbreviate code(]1/1) on the closing beam marker to code(]/1).
-
-mudela(fragment,verbatim)(
-< \type Staff = staffA {
- [/3 c'8 c'8 c'8 ]/1 c'4
- }
- \type Staff = staffB { [c''8 c''8] c''4 } >
-)
+beam, though: the spanners won't switch along.
+sect(Tuplets)
-bf(Important) the construct with code([/3) and
-code([/1) is a hack that sets a mode in the parser. This means that
-verb(id = \melodic { c8 c8 c8 }
-notATriplet =\melodic { [2/3 \id ]1/1 })
-does not produce a triplet. It will hopefully
-soon be replaced by a construction that mixes more elegantly with the
-grammar for Music.
-
-
-sect(Shortcuts for octaves)
-label(sec:relativeoctaves)
-
-Plain Mudela contains a lot of quotes to get the octaves right. This
-need for quotes can be reduced: most of the pitch intervals in
-conventional music are small. Therefore, it makes sense to leave out
-the quotes when the interval is small. We have built a mode that does
-exactly this. It is called the relative mode for octaves. You can
-switch it on by entering code(\relative). Then LilyPond will
-interpret every note as if they mean the note with the same name
-closest to the previous. You have to specify the first pitch because
-the first note of a list obviously has no predecessor. So, you can
-enter a scale without using octavation quotes, e.g.,
+The notes in a triplet take 2/3 of their notated duration. The syntax
+for triplet in LilyPond reflects this. To make a triplet, you enter
+COMMENT(
-mudela(fragment,verbatim)(
- \relative c' { c d e f g a b c }
-)
+)mudela(fragment,center)(
+ \type Voice \times 2/3 { c''4 c''4 c''4 }
+)COMMENT(
-For chords, the relative mode works slightly differently. In a
-sequence of chords, the first note of a chord gives the starting point
-for the next chord. We can demonstrate this with our twinkle twinkle example
-verb(
- \relative c' {
- c4 c <c g'> <c e g>
- <c e a> <b d a'> <b2 d g>
- <a4 d f> <bes d f> <bes c e> <g c e>
- <e a d> <a, g' cis'> <d2 f d'>
- }
-)
+)Since tuplet brackets are printed by the Voice context, a Voice
+context must exist before code(\times) is interpreted. To ensure this,
+a context is instantiated explicitly with code(\type Voice). You
+don't need this, if a Voice context is already instantiated, like in
+the following example:
+COMMENT(
-LilyPond converts any music with code(\relative) prepended to absolute
-music immediately when it is read. Internally it is stored it in
-absolute pitches. Since the tutorial mainly deals with how to specify
-musical information, and not how to enter it conveniently, the
-tutorial doesn't use it.
-
-
-sect(Large pieces)
-label(tutorial:large-pieces)
-
-In our quest for a clean and powerfull music language, we took the effort
-of entering some larger pieces of music as well. From this we learned
-certain things that lead to direct improvements of Mudela, such as the
-relative mode. We also gained some practial experience, that resulted in a
-compilation of tips that may be of use to you.
-
-Entering a large piece of music will often imply the need to produce a
-conductor's score, as well as individual parts for all instruments. This
-can most easily be achieved making use of identifiers and including mudela
-files.
-
-subsect(Identifiers)
-
-Briefly introduced before, identifiers are your biggest help in structurising
-a large piece of music. As an example, we'll consider a string quartet.
-In short, it will look like this: verb(
- global = \melodic{ }
- violinoOne = \melodic \relative c { .. }
- violinoTwo = \melodic \relative c { .. }
- viola = \melodic \relative c { .. }
- violoncello = \melodic \relative c { .. }
-)
+)mudela(fragment,center)(
+ c''4 \times 2/3 { c''4 c''4 c''4 } c''4
+)COMMENT(
-The code(\global) part contains everything that is global, i.e., the
-same, for each instrument. This may include time signature, key, repeat
-signs, different bar types, time signature- and key changes, rehearsal
-marks, etc.
-
-For each instrument, you'll have something vaguely resembling verb(
- violinoOneStaff = \type Staff = violinoOne <
- \property Staff.midi_instrument = "violin"
- \property Staff.instrument = "Violino I"
- \property Staff.instr = "Vl. I"
- \global
- \violinoOne
- >
)
-
-[Versions, relative mode,
- barchecks, splitting of files]
-
-subsect(Including Mudela files)
-ref(subsect:include)
-
-You can include other Mudela files with the command code(\include):
-verb(
-\include "paper13.ly"
-\score {
- ...
- \paper { \paper_thirteen }
-})
-
-The file is looked for in the standard search path.
-
-
-subsect(Grouping of staffs)
-
-subsect(Versioning)
-
-sect(Titling)
-label(tutorial:titling)
-
-A piece of sheet music isn't complete without proper opening and
-closing titles. LilyPond does not have any real support for setting
-text: that is a job best left to TeX(). But you can pass messages to
-TeX() from the input file. You can write TeX() macros to handle
-these messages.
-To do this, you add a code(\header) block
-to your input file. The format is quite simple,
-
-verb(
-\header{
- "key" = "value";
- "key" = "value";
- "key" = "value";
- % etc.
-})
-
-When the results of the music typesetting are output, the contents of
-code(\header) are also up into the TeX() file. Tools like
-code(ly2dvi) can use this information to generate pretty titling for
-your input file. Consult the manual page of code(ly2dvi) for more
-details.
-
-
-The code(\header) block should be at toplevel in mudela, and
-preferably at the top of the file. If you have an input file with
-multiple code(\score) blocks, you should add a header to every score,
-describing the different sub parts of the music piece, eg.
-
-
-verb(\header {
- "composer" = "Ludwig Van Bavaria";
- "title" = "Symphonie Megalomane";
- }
- \score{
- ... % some music
- \header { movement = "Mit roher Kraft wild herausfahrend!"; }
- \paper { }
- }
- \score{
- ... % some more music
- \header { movement = "Saut\'e comme un oeuf."; }
- \paper { }
- }
+Of course, you can also use different ratios, and use beamed notes or
+rests:
+mudela(fragment)(
+ \type Voice \times 4/5 { [c''8 c''16 c''16] r8 [g'8 g'8] }
)
+If you make a tuplet of beamed notes, where the beam is as wide as
+the bracket, the bracket is omitted.
-If you want you can also put the code(\header) block at the top of the
-input file; it will then be put into every output file automatically.
-This will make it clear what the file contains as soon as you open it.
-
-
+sect(Repeats)
projects / lilypond.git / blobdiff