-pl 15.jcn4
- - direct #... to scm parser (Tanks to Gary Houston)
+pl 15.hwn1
+ - reverted MIDI unfold patches.
+ - bf: cross staff beam, cross staff slur (2x)
+ - doco updates:
+ * metadoc/ -> programmer/ ,
+ * FAQ
+ * hacking
+ * index with logo
pl 15.jcn3
- - bf: smob fix?
+ - bf: smob fix
- mutopia/doc target 'local-web':
shorthand for 'CONFIGSUFFIX=www local-WWW'
+pl 15.lu2
+ - bf: close comments in website footer
+ - error messages for release didn't make it into .lu1?
pl 15.jcn2
- small website fixes
-
pl 15.jcn1
- bfs: initialise members of Column-x-positions and Break_node
- bf: Documentation/misc: don't include backups
- bf: .gdbinit
+pl 15.lu1
+ - error messages for failing diff/release
+ - \property noStemExtend: don't extend normal or beamed stems to
+ middle staff line: input/test/no-stem-extend.fly
+******
pl 15 (Oct 18)
14.jcn1
depth = ..
NAME = documentation
-SUBDIRS= user metadoc bibliography pictures topdocs ntweb misc
+SUBDIRS= user programmer bibliography pictures topdocs ntweb misc
STEPMAKE_TEMPLATES=documentation texinfo
README_TOP_FILES=NEWS DEDICATION CHANGES TODO
# ignore result since bib2html is nonstandard. Errors would halt the RPM build.j
$(outdir)/%.html: %.bib
-bib2html $< $@
- $(footify) $@
+# $(footify) $@
localclean:
rm -f fonts.aux fonts.log feta*.tfm feta*.*pk
@subsubsection Some of your neat scripts fail, what directories do you use:
-[This only applies if you don't do @code{make install}, and develop out
+[This only applies if you don't do @code{make install}, and run out
of the source directory]
I have a directory which contains all our development projects
@end example
-
-
-
-~/usr/src/bin is in the PATH, and contains symbolic links to the
-compiled executables.
+@file{~/usr/src/bin/} is in the variable PATH, and contains symbolic
+links to the compiled executables.
@subsubsection Is there an emacs mode?
Yes. It is included with the source archive as mudela-mode.el. If
-you have an rpm it is in /usr/doc/lilypond-X/. You have to install it
+you have an rpm it is in @file{/usr/doc/lilypond-X/}. You have to install it
yourself.
@subsubsection How do I create the @file{.tfm} files?
@subsubsection Why is the documentation/website/etc. so lousy?
-LilyPond development is moving quite fast, documentation will often
-lag a bit behind. We must always make a choice between writing more
-doco, writing more code and answering email.
+LilyPond development is moving quite fast, documentation will often lag
+a bit behind. We must always make a choice between writing more
+documentation, writing HTML, writing more code and answering email.
-If you think you can make a correction, or devised a solution that
-should be documented, please do so and send in a patch.
+If you think you can make a correction, or devised a solution that
+should be documented, please write it up, and us a diff.
@node Language- mudela, Do you support -, Documentation, FAQ - GNU LilyPond FAQs
@section Language: mudela
@subsubsection Do you support TAB notation?
-No. The same as for the previous subsubsection goes, but TAB is a lot
-more work than diagrams (TAB needs modification of Parser, Lexer,
-Staff, Notehead, Stem code and all the code that creates these graphic
-elements.)
+No. The same as for the previous subsubsection goes.
+
@subsubsection Do you support multiple staff-sizes?
-Yes. At this time you can choose between 11, 13, 16, 19, 20, 23 and
-20 pt staff-size. Use the staffLineLeading property for setting the
-size of the staff, and fontSize for setting the size of the glyphs.
+Yes. At this time you can choose between 11, 13, 16, 19, 20, 23 and 20
+pt staff-size. Use the @code{staffLineLeading} property for setting the
+size of the staff, and @code{fontSize} for setting the size of the
+glyphs.
@subsubsection Do you support Gregorian chant notation?
-No. Go ahead.
+No.
+
@subsubsection Do you support grace notes?
@subsubsection Could you implement feature XXXX? It is really easy, just extend the syntax to allow YYYY!
-If it is reasonable, I'll add XXXX to the TODO list. In general
-finding a cute syntax (such as YYYY) isn't very hard. The complicated
-issue how to adapt the internals to do XXXX. The parser is really a
-simple front end to the complicated internals.
+In general finding a cute syntax (such as YYYY) isn't very hard. The
+complicated issue how to adapt the internals to do XXXX. The parser is
+really a simple front end to the complicated internals.
@subsubsection Can I join in on LilyPond development? How do I do this?
-LilyPond development is open for anyone who wants to join. We do
-frequent releases, you are welcome to send in a patch or do suggestions.
-Join the gnu-music-discuss mailing list to participate.
+Yes, we do frequent releases, you are welcome to send in a patch or do
+suggestions. Join the list @email{gnu-music-discuss@@gnu.org} to
+participate.
-@subsubsection I want to implement XXXX! Should I do this?
-
-Yes.
-
-But since there might be better ways of doing XXXX, so it's a good thing to
-ask about this before you start hacking. If you want to keep in touch
-with current developments, you should subscribe to the mailing list
-
@subsubsection Is there a GUI frontend? Should I start building one?
-LilyPond currently has no graphical interface. The authors seriously
-doubt if a simple-minded approach (dragging and dropping notes) is any
-easier or quicker to use than mudela. But for composing a graphical
-environment probably is indispensable.
+LilyPond currently has no graphical interface. We (LilyPond authors)
+don't feel the need to write a GUI, but several others do:
Matthew Hiller has extended Midiscore and Koobase to handle mudela.
-Check out @uref{http://zoo.cs.yale.edu/~meh25/}.
+Check out @uref{http://zoo.cs.yale.edu/~meh25/}. He is now working on
+`Denemo', a GTK based notation program (which is still being developed).
-If you want to work on this, please send e-mail to the mailing list
-@email{gnu-music-discuss@@gnu.org}.
+Federico Mena-Quintero and Elliot Lee of RedHat Advanced Development
+labs have plans to write a GNOME based Music notation program. However,
+there is no code, only plans.
+
+Chris Cannam is working a rewrite of Rosegarden. The new design should
+be more modular, and could conceivably be used to output
+mudela. However, the not much seems to have happened the past year. See
+@uref{http://www.all-day-breakfast.com/rosegarden/development.html}.
@subsubsection I want to implement XXXX! How should I do this?
Please use the diff command to generate a patch, and don't send complete
files, even if the diff is larger than the whole file.
-Don't forget to put your name and e-mail address
-in the @file{AUTHORS.pod} file, or you won't get credits :-]
+Don't forget to put your name and e-mail address in the file
+@file{Documentation/topdocs/AUTHORS.texi}, or you won't get credits
+:-)
@subsubsection Your make system does not adhere to GNU coding standards, could you please fix it?
No. We have evaluated the standard GNU combination for compiling
-programs (autoconf, automake, libtool) and found to be inadequate in
-several respects. More detailed argumentation is included with
-LilyPond's generic make package @code{StepMake}
-(see @file{stepmake-x.x.x/Documentation/automake.urgh})
-
-LilyPond already compiles into a different directory ((the different
-directory is called out/, there is one in every source directory).
-make distclean essentially reduces to @file{rm -f out/*} in every directory
+programs (autoconf, automake, libtool) and found to be inadequate for
+our needs.
@subsubsection gdb crashes when I debug!
-Upgrade to 4.17.
-
-@subsubsection Why do I need g++ >= 2.8 / EGCS-1.1 ?
-
-Supporting more compilers than EGCS/G++ 2.8 is unlikely to make
-LilyPond run on more platforms. It would give us an enormous headache
-in detecting and catering for every variant of every compiler: not
-having to support other compilers saves us a @emph{lot} of trouble.
+Upgrade/downgrade to 4.17.
@node Running, Copyright, Development, FAQ - GNU LilyPond FAQs
@section Running
The beams and slurs are done in PostScript. XDvi doesn't show
PostScript in the magnifying glass. Complain to the XDvi maintainers.
-@subsubsection I don't get midi-output, even if I use @strong{-m}!
-
-Your \score should include a \midi block, eg.
-@example
-
- \score @{
- \melodic @{ c4 c g g @}
- \paper @{@}
- \midi @{
- output = "myfile.midi";
- \tempo 4=70;
- @}
- @}
-
-@end example
-
-The @strong{-m} option was added to LilyPond to suppress paper output,
-because processing the \paper block is so slow.
@subsubsection A lot of musical stuff doesn't make it to the MIDI file, eg. dynamics, articulation, etc.
* ENV:WEBMASTER,
* ENV:WEBMASTER
->
+-->
<hr>
Go <a href=%s>back</a> to index of LilyPond.
<em>gnu-music-discuss@gnu.org</em></a>.
<p>
-<!-- package %s %s >
+<!-- package %s %s -->
Please send comments on these web pages to
<a href="mailto:%s"><em>%s</em></a>
@item @uref{faq.html,Frequently asked questions}, with answers
@item @uref{programs.html,`Manual pages'}
@item @uref{../user/out-www/index.html,User documentation}
-@item @uref{../metadoc/out-www/index.html,Hacker documentation}
+@item @uref{../programmer/out-www/index.html,Programmer's documentation}
@item @uref{../bibliography/out-www/index.html,Bibliography}
@item @uref{../misc/out-www/index.html,Miscellaneous texts}
@end itemize
@unnumberedsubsec Logo:
@itemize
@item @uref{../pictures/out-www/lelieblond.png, logo} in large size
-@item @uref{../pictures/out-www/lelie_logo.png, logo} in medium size
+@item @uref{../pictures/out-www/lelie-logo.png, logo} in medium size
+@item @uref{../pictures/out-www/lelie-icon.png, logo} in small size
@end itemize
@bye
+++ /dev/null
-# Documentation/tex/Makefile
-
-depth=../..
-
-TEX_FILES = $(wildcard *.tex)
-DOC_FILES = $(wildcard *.doc)
-DVI_FILES = $(addprefix $(outdir)/,$(DOC_FILES:.doc=.dvi) $(TELY_FILES:.tely=.dvi))
-
-OUTTEX_FILES = $(addprefix $(outdir)/, $(TEX_FILES))
-OUTDOC_FILES = $(addprefix $(outdir)/, $(DOC_FILES))
-
-EXTRA_DIST_FILES= $(DOC_FILES) $(TEX_FILES) $(wildcard *.sty)
-HTML_FILES = $(addprefix $(outdir)/, $(TEXI_FILES:.texi=.html) $(TELY_FILES:.tely=.html))
-PS_FILES = $(DVI_FILES:.dvi=.ps)
-
-STEPMAKE_TEMPLATES=tex documentation texinfo
-LOCALSTEPMAKE_TEMPLATES=lilypond mudela
-
-export BIBINPUTS:=$(shell pwd)//$(PATHSEP)$(BIBINPUTS)
-include $(depth)/make/stepmake.make
-
-dvi: $(DVI_FILES)
-
-ps: $(PS_FILES)
-
-# urg
-default:
-
-
-localclean:
- rm -f fonts.aux fonts.log feta*.tfm feta*.*pk
-
-local-WWW: $(HTML_FILES)
- $(PYTHON) $(step-bindir)/ls-latex.py --title 'Hacker documentation' \
- $(DOC_FILES) $(TEXI_FILES) $(TELY_FILES) \
- | sed "s!$(outdir)/!!g" > $(outdir)/index.html
+++ /dev/null
-% Creator: mf-to-table.py version 0.7
-% Automatically generated on
-% Do not edit
-% input from out/feta20.log
-% name
-% rests
-\fetdef\wholerest{0}
-\fetdef\halfrest{1}
-\fetdef\outsidewholerest{2}
-\fetdef\outsidehalfrest{3}
-\fetdef\breverest{4}
-\fetdef\longarest{5}
-\fetdef\multirest{6}
-\fetdef\quartrest{7}
-\fetdef\eighthrest{8}
-\fetdef\sixteenthrest{9}
-\fetdef\thirtysecondrest{10}
-\fetdef\sixtyfourthrest{11}
-\fetdef\hundredtwentyeighthrest{12}
-
-% accidentals
-\fetdef\sharp{13}
-\fetdef\natural{14}
-\fetdef\flat{15}
-\fetdef\flatflat{16}
-\fetdef\sharpsharp{17}
-\fetdef\rightparen{18}
-\fetdef\leftparen{19}
-
-% dots
-\fetdef\dot{20}
-\fetdef\repeatcolon{21}
-
-% balls
-\fetdef\brevisball{22}
-\fetdef\brevisledger{23}
-\fetdef\longaball{24}
-\fetdef\longaledger{25}
-\fetdef\wholeball{26}
-\fetdef\wholeledger{27}
-\fetdef\halfball{28}
-\fetdef\halfledger{29}
-\fetdef\quartball{30}
-\fetdef\quartledger{31}
-
-% scripts
-\fetdef\ufermata{32}
-\fetdef\dfermata{33}
-\fetdef\thumb{34}
-\fetdef\sforzatoaccent{35}
-\fetdef\staccato{36}
-\fetdef\ustaccatissimo{37}
-\fetdef\dstaccatissimo{38}
-\fetdef\tenuto{39}
-\fetdef\umarcato{40}
-\fetdef\dmarcato{41}
-\fetdef\ouvert{42}
-\fetdef\plusstop{43}
-\fetdef\upbow{44}
-\fetdef\downbow{45}
-\fetdef\reverseturn{46}
-\fetdef\turn{47}
-\fetdef\trill{48}
-\fetdef\upedalheel{49}
-\fetdef\dpedalheel{50}
-\fetdef\upedaltoe{51}
-\fetdef\dpedaltoe{52}
-\fetdef\flageolet{53}
-\fetdef\trilelement{54}
-\fetdef\prall{55}
-\fetdef\mordent{56}
-\fetdef\prallprall{57}
-\fetdef\prallmordent{58}
-\fetdef\upprall{59}
-\fetdef\downprall{60}
-\fetdef\accDiscant{61}
-\fetdef\accDiscantF{62}
-\fetdef\accDiscantEh{63}
-\fetdef\accDiscantE{64}
-\fetdef\accDiscantFE{65}
-\fetdef\accDiscantFEh{66}
-\fetdef\accDiscantEE{67}
-\fetdef\accDiscantFEE{68}
-\fetdef\accDiscantEEE{69}
-\fetdef\accDiscantFEEE{70}
-\fetdef\accDiscantS{71}
-\fetdef\accDiscantFS{72}
-\fetdef\accDiscantES{73}
-\fetdef\accDiscantEhS{74}
-\fetdef\accDiscantFES{75}
-\fetdef\accDiscantFEhS{76}
-\fetdef\accDiscantEES{77}
-\fetdef\accDiscantFEES{78}
-\fetdef\accDiscantEEES{79}
-\fetdef\accDiscantFEEES{80}
-\fetdef\accDiscantSS{81}
-\fetdef\accDiscantESS{82}
-\fetdef\accDiscantEESS{83}
-\fetdef\accDiscantEEESS{84}
-\fetdef\accFreebass{85}
-\fetdef\accFreebassF{86}
-\fetdef\accFreebassE{87}
-\fetdef\accFreebassFE{88}
-\fetdef\accStdbass{89}
-\fetdef\accStdbassM{90}
-\fetdef\accStdbassBp{91}
-\fetdef\accStdbassT{92}
-\fetdef\accStdbassTp{93}
-\fetdef\accBayanbass{94}
-\fetdef\accBayanbassT{95}
-\fetdef\accBayanbassE{96}
-\fetdef\accBayanbassTE{97}
-\fetdef\accBayanbassEE{98}
-\fetdef\accBayanbassTEE{99}
-\fetdef\accSB{100}
-\fetdef\accBB{101}
-\fetdef\accOldEE{102}
-\fetdef\accOldEES{103}
-
-% flags
-\fetdef\eighthflag{104}
-\fetdef\sixteenthflag{105}
-\fetdef\thirtysecondflag{106}
-\fetdef\sixtyfourthflag{107}
-\fetdef\deighthflag{108}
-\fetdef\dsixteenthflag{109}
-\fetdef\dthirtysecondflag{110}
-\fetdef\dsixtyfourthflag{111}
-
-% clefs
-\fetdef\altoclef{112}
-\fetdef\caltoclef{113}
-\fetdef\bassclef{114}
-\fetdef\cbassclef{115}
-\fetdef\trebleclef{116}
-\fetdef\ctrebleclef{117}
-
-% timesig
-\fetdef\fourfourmeter{118}
-\fetdef\allabreve{119}
-\fetdef\oldfourfourmeter{120}
-\fetdef\oldallabreve{121}
-\fetdef\oldthreetwometer{122}
-\fetdef\oldsixfourmeter{123}
-\fetdef\oldninefourmeter{124}
-
+++ /dev/null
-
- % -*-LaTeX-*-
-
-\documentclass{article}
-\def\kdots{,\ldots,}
-\title{Not the Font-En-Tja font}
-\author{HWN \& JCN}
-\def\preMudelaExample{}
-\def\postMudelaExample{}
-\begin{document}
-\maketitle
-
-
-\section{Introduction}
-
-This document are some design notes of the Feta font, and other
-symbols related to LilyPond. Feta (not an abbreviation of
-Font-En-Tja) is a font of music symbols. All MetaFont sources are
-original. The symbols are modelled after various editions of music,
-notably \begin{itemize} \item B\"arenreiter \item Hofmeister \item
-Breitkopf \item Durand \& C'ie \end{itemize}
-
-The best references on Music engraving are Wanske\cite{wanske} and
-Ross\cite{ross} some of their insights were used. Although it is a
-matter of taste, I'd say that B\"arenreiter has the finest typography
-of all.
-
-
-\section{Bezier curves for slurs}
-
-Objective: slurs in music are curved objects designating that notes
-should fluently bound. They are drawn as smooth curves, with their
-center thicker and the endings tapered.
-
-There are some variants: the simplest slur shape only has the width as
-parameter. Then we give some suggestions for tuning the shapes. The
-simple slur algorithm is used for drawing ties as well.
-
-
-
-\subsection{Simple slurs}
-
-Long slurs are flat, whereas short slurs look like small circle arcs.
-Details are given in Wanske\cite{ross} and Ross\cite{wanske}. The
-shape of a slur can be given as a Bezier curve with four control
-points:
-
-\begin{eqnarray*}
- B(t) &=& (1-t)^3c_1 +3(1-t)^2tc_2 + 3(1-t)t^2c_3 + t^3c_4.
-\end{eqnarray*}
-
-We will assume that the slur connects two notes of the same
-pitch. Different slurs can be created by rotating the derived shape.
-We will also assume that the slur has a vertical axis of symmetry
-through its center. The left point will be the origin. So we have
-the following equations for the control points $c_1\kdots c_4$.
-
-\begin{eqnarray*}
-c_1&=& (0,0)\\
-c_2&=& (i, h)\\
-c_3&=& (b-i, h)\\
-c_4&=& (b, 0)
-\end{eqnarray*}
-
-The quantity $b$ is given, it is the width of the slur. The
-conditions on the shape of the slur for small and large $b$ transform
-to
-\begin{eqnarray*}
- h \to h_{\infty} , &&\quad b \to \infty\\
- h \approx r_{0} b, &&\quad b \to 0.
-\end{eqnarray*}
-To tackle this, we will assume that $h = F(b)$, for some kind of
-$F(\cdot)$. One function that satisfies the above conditions is
-$$
-F(b) = h_{\infty} \frac{2}{\pi} \arctan \left( \frac{\pi r_0}{2
-h_{\infty}} b \right).
-$$
-
-For satisfying results we choose $h_{\infty} = 2\cdot \texttt{interline}$
-and $r_0 = \frac 13$.
-
-\subsection{Height correction}
-
-Aside from being a smooth curve, slurs should avoid crossing
-enclosed notes and their stems.
-
-An easy way to achieve this is to extend the slur's height,
-so that the slur will curve just above any disturbing notes.
-
-The parameter $i$ determines the flatness of the curve. Satisfying
-results have been obtained with $i = h$.
-
-The formula can be generalised to allow for corrections in the shape,
-\begin{eqnarray*}
-c_1&=& (0,0)\\
-c_2&=& (i', h')\\
-c_3&=& (b-i', h')\\
-c_4&=& (b, 0)
-\end{eqnarray*}
-Where
-$$
-i' = h(b) (1 + i_{corr}), \quad h' = h(b) (1 + h_{corr}).
-$$
-
-The default values for these corrections are $0$. A $h_{corr}$ that is
-negative, makes the curve flatter in the center. A $h_{corr}$ that is
-positive make the curve higher.
-
-At every encompassed note's x position the difference $\delta _y$
-between the slur's height and the note is calculated. The greatest
-$\delta _y$ is used to calculate $h_{corr}$ is by lineair extrapolation.
-
-However, this simple method produces satisfactory results only for
-small and symmetric disturbances.
-
-
-\subsection{Tangent method correction}
-
-A somewhat more elaborate\footnote{While staying in the realm
-of empiric computer science} way of having a slur avoid
-disturbing notes is by first defining the slur's ideal shape
-and then using the height correction. The ideal shape of a
-slur can be guessed by calculating the tangents of the disturbing
-notes:
-% a picture wouldn't hurt...
-\begin{eqnarray*}
- y_{disturb,l} &=& \rm{rc}_l x\\
- y_{disturb,r} &=& \rm{rc}_r + c_{3,x},
-\end{eqnarray*}
-where
-\begin{eqnarray*}
- \rm{rc}_l &=& \frac{y_{disturb,l} - y_{encompass,1}}
- {x_{disturb,l} - x_{encompass,1}}\dot x\\
- \rm{rc}_r &=& \frac{y_{encompass,n} - y_{disturb,r}}
- {x_{encompass,n} - x_{disturb,r}} \dot x + c_{3,x}.
-\end{eqnarray*}
-
-We assume that having the control points $c_2$ and $c_3$ located
-on tangent$_1$ and tangent$_2$ resp.
-% t: tangent
-\begin{eqnarray*}
- y_{tangent,l} &=& \alpha \rm{rc}_l x\\
- y_{tangent,r} &=& \alpha \rm{rc}_r + c_{3,x}.
-\end{eqnarray*}
-
-Beautiful slurs have rather strong curvature at the extreme
-control points. That's why we'll have $\alpha > 1$.
-Satisfactory resulsts have been obtained with
-$$
- \alpha \approx 2.4.
-$$
-
-The positions of control points $c_2$ and $c_3$ are obtained
-by solving with the height-line
-\begin{eqnarray*}
- y_h &=& \rm{rc}_h + c_h.
-\end{eqnarray*}
-
-The top-line runs through the points disturb$_{left}$ and
-disturb$_{right}$. In the case that
-$$
-z_{disturb,l} = z_{disturb,r},
-$$
-we'll have
-$$
- \angle(y_{tangent,l},y_h) = \angle(y_{tangent,r},y_h).
-$$
-
-
-
-\section{Sizes}
-
-Traditional engraving uses a set of 9 standardised sizes for Staffs
-(running from 0 to 8).
-
-We have tried to measure these (helped by a magnifying glass), and
-found the staffsizes in table~\ref{fonts:staff-size}. One should note that
-these are estimates, so I think there could be a measuring error of ~
-.5 pt. Moreover [Ross] states that not all engravers use exactly
-those sizes.
-
-\begin{table}[h]
- \begin{center}
- \begin{tabular}{lll}
-Staffsize &Numbers &Name\\
-\hline\\
-26.2pt &No. 0\\
-22.6pt &No. 1 &Giant/English\\
-21.3pt &No. 2 &Giant/English\\
-19.9pt &No. 3 &Regular, Ordinary, Common\\
-19.1pt &No. 4 &Peter\\
-17.1pt &No. 5 &Large middle\\
-15.9pt &No. 6 &Small middle\\
-13.7pt &No. 7 &Cadenza\\
-11.1pt &No. 8 &Pearl\\
- \end{tabular}
- \caption{Foo}
- \label{fonts:staff-size}
- \end{center}
-\end{table}
-
-
-
-
-\section{Beams}
-
-\subsection{Slope}
-
-Traditionally, beam slopes are computed by following a large and hairy
-set of rules. Some of these are talked-about in Wanske, a more
-recipy-like description can be found in Ross.
-
-There are some problems when trying to follow these rules:
-\begin{itemize}
-
-\item the set is not complete
-
-\item they are not formulated as a general rule with exceptions, but
-rather as a huge case of individual rules\cite{ross}
-
-\item in some cases, the result is wrong or ugly (or both)
-
-\item they try to solve a couple of problems at a time (e.g. Ross
-handles ideal slope and slope-quantisation as a paired problem)
-\end{itemize}
-Reading Ross it is clear that the rules presented there are certainly
-not the ultimate idea of what beam(slope)s should look like, but
-rather a (very much) simplified hands-on recipy for a human engraver.
-
-There are good reasons not to follow those rules:
-
-\begin{itemize}
-\item One cannot expect a human engraver to solve least-squares
-problems for every beam
-
-\item A human engravers will allways trust themselves in judging the
-outcome of the applied recipy. If, in a complicated case, the result
-"doesn't look good", they will ignore the rules and draw their own
-beams, based on experience.
-
-\item The exact rules probably don't "really exist" but in the minds
- of good engravers, in the form of experience
-\end{itemize}
-
-We'll propose to do a least-squares solve. This seems to be the best
-way to calculate the slope for a computerised engraver such as Lily.
-
-It would be nice to have some rules to catch and handle "ugly" cases,
-though. In general, the slope of the beam should mirror the pitches
-of the notes. If this can't be done because there simply is no
-uniform trend, it would probably be best to set the slope to zero.
-
-
-\subsection{Quantising}
-
-The beams should be prevented to conflict with the stafflines,
-especially at small slopes. Traditionally, poor printing techniques
-imposed rather strict rules for quantisation. In modern (post 1955)
-music printing we see that quality has improved substantially and
-obsoleted the technical justification for following some of these
-strict rules, notably the avoiding of so-called wedges.
-
-
-\subsection{Thickness and spacing}
-
-The spacing of double and triple beams (sixteenth and thirtysecond beams)
-is the same, quadruple and quintuple (thirtyfourth and hundredtwentyeighth
-beams) is wider.
-All beams are equally thick. Using the layout of triple beams and the
-beam-thickness $bt$ we can calculate the inter-beam spacing $ib$.
-
-Three beams span two interlines, including stafflines:
-\begin{eqnarray*}
- 2 ib + bt &=& 2 il\\
- ib &=& (2 il - bt) / 2
-\end{eqnarray*}
-
-We choose
-\begin{eqnarray*}
- bt &=& 0.48(il - st)
-\end{eqnarray*}
-
-\subsubsection{Quadruple beams}
-
-If we have more than three beams they must open-up
-in order to not collide with staff lines. The only valid
-position that remains is for the upper beam to hang.
-
-\begin{eqnarray*}
- 3 ib_{4+} + bt &=& 3 il\\
- ib_{4+} &=& (3 il - bt) / 3
-\end{eqnarray*}
-
-
-\section{Layout of the source files}
-
-The main font (with the fixed size music glyphs) uses a the \TeX\
-logfile as a communication device. Use the specialised macros to
-create and export glyphs.
-
-\bibliographystyle{plain}
-\bibliography{engraving}
-
-
-
-\end{document}
-
-\begin{verbatim}
-Paul Terry <paul@musonix.demon.co.uk> writes:
-
-Ross states that the dies (the stamps to make the symbols) come in
-12 different sizes.
-
->Can you tell me how big rastrals are?
-
-According to the Score manual:
-
- Rastral Size Height in millimetres
-
- 0 9 mm
- 1 8 mm
- 2 7.5 mm
- 3 7 mm
- 4 6.5 mm
- 5 6 mm
- 6 5.5 mm
-
-I must say, despite having been a music setter for many years, I had to
-look these up - none of the publishers I work for deal in Rastral sizes
-these days (they all use millimetres).
+++ /dev/null
-\input texinfo @c -*-texinfo-*-
-@setfilename internals.info
-@settitle LilyPond internals
-
-@node Top, LilyPond internals, (dir), (dir)
-@top
-
-
-@menu
-* LilyPond internals::
-* Overview::
-* mudela::
-* Request_engraver::
-* Graphic elements::
-* Score elements::
-* Items::
-* Spanners::
-* Future work::
-* Coding standards::
-* Making patches::
-
-@end menu
-
-@node LilyPond internals, , Top, Top
-@menu
-* Overview:: Overview
-* mudela:: mudela
-* Request_engraver:: Request_engraver
-@end menu
-
-
-@chapter Help Needed!
-
-[Call for help]
-
-[List tasks:
-
-* Mutopia
-
-* Doco LilyPond
-
-* Straightforward extensions
-
-* GUI editors.
-
-]
-
-@chapter LilyPond internals
-
-
-This documents some aspects of the internals of GNU LilyPond. Some of
-this stuff comes from e-mail I wrote, some from e-mail others wrote,
-some are large comments taken away from the headers. This page may be
-a little incoherent. Unfortunately, it is also quite outdated. A
-more thorough and understandable document is in the works.
-
-You should use @code{doc++} to take a peek at the sources.
-
-@node Overview, mudela, Top, Top
-@section Overview
-
-GNU LilyPond is a "multi-pass" system. The different passes have been
-created so that they do not depend on each other. In a later stage
-some parts may be moved into libraries, or seperate programs, or they
-might be integrated in larger systems.
-
-@table @samp
-
-@item Parsing:
-
-No difficult algorithms. The .ly file is read, and converted to a list
-of @code{Scores}, which each contain @code{Music} and paper/midi-definitions.
-
-@item Interpreting music
-
-The music is walked through in time-order. The iterators which do the
-walking report Music to Translators which use this information to
-create elements, either MIDI or "visual" elements. The translators
-form a hierarchy; the ones for paper output are Engravers, for MIDI
-Performers.
-
-The translators swallow Music (mostly atomic gobs called Requests),
-create elements, broadcast them to other translators on higher or same
-level in the hierarchy:
-
-The stem of a voice A is broadcast to the staff which contains A, but
-not to the stems, beams and noteheads of a different voice (say B) or
-a different staff. The stem and noteheads of A are coupled, because
-the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
-these.
-
-The engraver which agrees to handle a request decides whether to to
-honor the request, ignore it, or merge it with other requests. Merging
-of requests is preferably done with other requests done by members of
-the same voicegroups (beams, brackets, stems). In this way you can put
-the voices of 2 instruments in a conductor's score so they make chords
-(the Beam requests of both instruments will be merged).
-
-@item Prebreaking
-
-Breakable stuff (eg. clefs and bars) are copied into pre and
-postbreaks.
-
-@item Preprocessing
-
-Some dependencies are resolved, such as the direction of stems, beams,
-and "horizontal" placement issues (the order of clefs, keys etc,
-placement of chords in multi-voice music),
-
-@item Break calculation:
-
-The lines and horizontal positions of the columns are determined.
-
-@item Breaking
-
-Through some magical interactions with Line_of_score and Super_elem
-(check out the source) the "lines" are produced.
-
-All other spanners can figure across which lines they are spread. If
-applicable, they break themselves into pieces. After this, each piece
-(or, if there are no pieces, the original spanner itself) throws out
-any dependencies which are in the wrong line.
-
-@item Postprocesing:
-
-Some items and all spanners need computation after the Paper_column
-positions are determined. Examples: slurs, vertical positions of
-staffs.
-
-@item Output paper
-
-@end table
-
-@node mudela, Request_engraver, Overview, Top
-@section mudela
-
-Most information is stored in the form of a request. In music
-typesetting, the user might want to cram a lot more symbols on the
-paper than actually fits. To reflect this idea (the user asks more
-than we can do), the container for this data is called Request.
-
-In a lot of other formats this would be called an 'Event'
-
-@table @samp
-@item @code{Barcheck_req}
- Checks during music processing if start of this voice element
- coincides with the start of a measure. Handy to check if you left out
- some voice elts.
-@item @code{Note_req}
- LilyPond has to decide if the ball should be hanging left or
- right. This influences the horizontal dimensions of a column, and this
- is why request processing should be done before horizontal spacing.
- Other voices' frivolities may cause the need for accidentals, so this
- is also for the to decide. The engraver can decide on positioning based on
- ottava commands and the appropriate clef.
-@item @code{Rest_req}
- Typeset a rest.
-@item @code{Span_req}
- This type of request typically results in the creation of a @code{Spanner}
-@item @code{Beam_req}
- Start/stop a beam.
- Engraver has to combine this request with the stem_request, since the
- number of flags that a stem wants to carry will determine the
- number of beams.
-@item @code{Dynamic}
- Each dynamic is bound to one note (a crescendo spanning multiple
- notes is thought to be made of two "dynamics": a start and a stop).
- Dynamic changes can occur in a smaller time than the length of its
- note, therefore fore each @code{Dynamic} request carries a time, measured
- from the start of its note.
-@end table
-
-@node Request_engraver, , mudela, Top
-@section Request_engraver
-
-In the previous section the idea of Request has been explained, but
-this only solves one half of the problem. The other half is deciding
-which requests should be honored, which should merged with other
-requests, and which should be ignored. Consider this input
-
-@example
-
- \type Staff < % chord
- @{ \meter 2/4; [c8 c8] @}
- @{\meter 2/4; [e8 e8] @}
- >
-
-@end example
-
-Both the cs and es are part of a staff (they are in the same
-Voice_group), so they should share meters, but the two [ ] pairs
-should be merged.
-
-The judge in this "allocation" problem a set of brokers: the requests
-are transmitted to so-called engravers which respond if they want to
-accept a request eg, the @code{Notehead_engraver} will accept
-@code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator
-cannot find a engraver that wants the request, it is junked (with a
-warning message).
-
-After all requests have been either assigned, or junked, the Engraver
-will process the requests (which usually means creating an @code{Item}
-or @code{Spanner}). If a @code{Request_engraver} creates something, it
-tells the enclosing context. If all items/spanners have been created,
-then each Engraver is notified of any created Score_element, via a
-broadcasting system.
-
-@unnumberedsubsec example:
-
-@example
-
- c4
-
-@end example
-
-produces:
-
-@example
-
- Note_request (duration 1/4)
- Stem_request (duration 1/4)
-
-@end example
-
-Note_request will be taken by a @code{Notehead_engraver}, stem_request
-will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver}
-creates a @code{Notehead}, @code{Stem_beam_engraver} creates a
-@code{Stem}. Both announce this to the Staff_engraver. Staff_engraver
-will tell @code{Stem_beam_engraver} about the @code{Notehead}, which
-will add the @code{Notehead} to the @code{Stem} it just created.
-
-To decide on merging, several engravers have been grouped. Please
-check @file{init/engraver.ly}.
-
-
-
-@node Graphic elements, , , Top
-@section Graphic elements
-
-
-Music notation is composed of a sets of interrelated glyphs. In
-Lilypond every glyph usually is represented by one object, a so-called
-Graphic Object. The primary relations between graphic objects involve
-positions:
-
-@itemize
-@item consecutive notes are printed left to right, grouped in a staff
-@item simultaneous notes are horizontally aligned (internally grouped in
-a paper column).
-@item the staccato mark is horizontally centered on the note it applies
-to.
-@end itemize
-
-The abstract encoding of such relations is done with the concept
-@dfn{reference point}. The reference point (in X direction) of the
-staccato mark is the note it applies to. The (X) position of the
-staccato mark is stored relative to the position of the note head. This
-means that the staccato will always maintain a fixed offset wrt to the
-note head, whereever the head is moved to.
-
-In the same vein, all notes on a staff have their Y positions stored
-relative to an abstract object called Axis_group_spanner. If the
-Axis_group_spanner of one staff is moved, the absolute Y positions of
-all objects in that spanner change along, in effect causing the staff
-and all its contents to move as a whole.
-
-Each graphic object stores a pointer and an relative offset for each
-direction: one for the X-axis, one for the Y-axis. For example, the X
-parent of a Note_head usually is a Note_column. The X parent of a
-Note_column usually is either a Collision or a Paper_column. The X
-parent of a Collision usually is a Paper_column. If the Collision
-moves, all Note_heads that have that Collision as parent also move, but
-the absolute position of the Paper_column does not change.
-
-To build a graphical score with Graphic_elements, conceptually, one
-needs to have one Root object (in Lilypond: Line_of_score), and
-recursively attach objects to the Root. However, due to the nature
-of the context selection mechanisms, it turns out to be more
-advantageous to construct the tree the other way around: first small
-trees (note heads, barlines etc.) are created, and these are
-subsequently composed into larger trees, which are finally hung on a
-Paper_column (in X direction) or Line_of_score (in Y direction).
-
-The structure of the X,Y parent relations are determined by the
-engravers and notation contexts:
-
-The most important X-axis parent relation depends on the timing: notes
-that come earlier are attached to Paper_column that will be positioned
-more to the left.
-
-The most important Y-axis relation depends on containment of contexts:
-notes (created in a Thread or Voice context) are put in the staff where
-the originating context lives in.
-
-Graphical_axis_groups are special graphic objects, that are designed to
-function as a parent. The size of a Graphical_axis_groups group is the
-union of its children.
-
-@node Score elements, , , Top
-
-Besides relative positions there are lots of other relations between
-elements. Lilypond does not contain other specialized relation
-management (Like the relative positioning code). In stead, objects can
-be connected through dependencies, which sets the order in which objects
-are to be processed.
-
-Example: the direction of a beamed stem should equal the direction of
-the beam. When the stem is a added to the beam, a dependency on the
-beam is set in the stem: this means that @code{Beam::do_pre_processing
-()} (which does various direction related things) will be called before
-@code{Stem::do_pre_processing ()}.
-
-The code that manages dependencies resides in the class
-@code{Score_element}, a derived class of @code{Graphical_element}. The
-bulk of the code handles line breaking related issues.
-
-To sketch the problems with line breaking: suppose a slur spans a line
-break,
-@example
-
-c4( c'''' c | \break d d )d
-
-@end example
-In this case, the slur will appear as two parts, the first part spanning
-the first three notes (the @code{c}s), the second spanning the last
-three (the @code{d}s). Within Lilypond this is modeled as breaking the
-slur in parts: from the Original slur, two new clones of the old slur
-are made. Initially both clones depend on the six notes. After the
-hairy code in Score_element, Spanner and Item which does substitutions
-in sets of dependencies, the first clone depends on the first three
-notes, the second on the last three.
-
-The major derived classes of Score_element are Item and Spanner.
-An item has one horizontal position. A spanner hangs on two items.
-
-@node Items, , , Top
-@section Items
-
-
-
-An item is a score element that is associated with only one
-Paper_column. Examples are note heads, clefs, sup and superscripts, etc.
-Item is a derived class of Score_element.
-
-The shape of an item is known before the break calculations, and line
-spacing depends on the size of items: very wide items need more space
-than very small ones.
-
-An additional complication is the behavior of items at linebreaks. For
-example, when you do a time signature change, you get only one symbol.
-If it occurs at a linebreak, the new time signature must be printed both
-before and after the linebreak. Other `breakable symbols' such as
-clefs, and bar lines also exhibit this behavior.
-
-if a line of music is broken, the next line usually gets a clef. So in
-TeX terms, the clef is a postbreak. The same thing happens with meter
-signs: Normally the meter follows the bar. If a line is broken at that
-bar, the bar along with the meter stays on the "last" line, but the next
-line also gets a meter sign after the clef. To support this,
-breakable items are generated in the three versions: original
-(unbroken), left (before line break) and right (after line break).
-During the line spacing, these versions are used to try how the spacing
-of a line works out.
-
-Once the definitive spacing is determined, dependencies (and various
-other pointers) are substituted such that all dependencies point at the
-active items: either they point at the original, or they point at left
-and right.
-
-@node Spanners, , , Top
-@section Spanners
-
-Spanners are symbols that are of variable shape, eg. Slurs, beams, etc.
-Spanners is a derived class of Score_element.
-
-The final shape can only be determined after the line breaking process.
-All spanners are spanned on two items, called the left and right
-boundary item. The X reference point is the left boundary item.
-
-
-@node Future work, , , Top
-@section Future work
-
-There are plans to unify Spanner and Item, so there will no longer be
-such a clear distinction between the two. Right now, Score_elements are
-always either Item or either Spanner.
-
-Most of the properties of a graphic object are now member variables of
-the classes involved. To offer configurability, we want to move these
-variables to scheme (GUILE) variables, and no longer use C++ code to
-calculate them, but use Scheme functions.
-
-@node Coding standards, , , Top
-
-@chapter CodingStyle - standards while programming for GNU
-LilyPond
-
-Functions and methods do not return errorcodes.
-
-
-@unnumberedsubsec Languages
-
-C++ and Python are preferred. Perl is not. Python code should use an
-indent of 8, using TAB characters.
-
-@unnumberedsubsec Filenames
-
-Definitions of classes that are only accessed via pointers
-(*) or references (&) shall not be included as include files.
-
-filenames
-
-@example
- ".hh" Include files
- ".cc" Implementation files
- ".icc" Inline definition files
- ".tcc" non inline Template defs
-@end example
-
-in emacs:
-
-@example
- (setq auto-mode-alist
- (append '(("\\.make$" . makefile-mode)
- ("\\.cc$" . c++-mode)
- ("\\.icc$" . c++-mode)
- ("\\.tcc$" . c++-mode)
- ("\\.hh$" . c++-mode)
- ("\\.pod$" . text-mode)
- )
- auto-mode-alist))
-@end example
-
-
-The class Class_name_abbreviation is coded in @file{class-name-abbr.*}
-
-@unnumberedsubsec Indentation
-
-Standard GNU coding style is used. In emacs:
-
-@example
- (add-hook 'c++-mode-hook
- '(lambda() (c-set-style "gnu")
- )
- )
-@end example
-
-If you like using font-lock, you can also add this to your @file{.emacs}:
-
-@example
- (setq font-lock-maximum-decoration t)
- (setq c++-font-lock-keywords-3
- (append
- c++-font-lock-keywords-3
- '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
- ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
- ))
-@end example
-
-@unnumberedsubsec Classes and Types
-
-@example
- This_is_a_class
-@end example
-
-@unnumberedsubsec Members
-
-@example
- Class::member ()
- Type Class::member_type_
- Type Class::member_type ()
-@end example
-
-the @code{type} is a Hungarian notation postfix for @code{Type}. See below
-
-@unnumberedsubsec Macros
-
-Macros should be written completely in uppercase
-
-The code should not be compilable if proper macro declarations are not
-included.
-
-Don't laugh. It took us a whole evening/night to figure out one of
-these bugs, because we had a macro that looked like
-@code{DECLARE_VIRTUAL_FUNCTIONS ()}.
-
-@unnumberedsubsec Broken code
-
-Broken code (hardwired dependencies, hardwired constants, slow
-algorithms and obvious limitations) should be marked as such: either
-with a verbose TODO, or with a short "ugh" comment.
-
-@unnumberedsubsec Comments
-
-The source is commented in the DOC++ style. Check out doc++ at
-@uref{http://www.zib.de/Visual/software/doc++/index.html}
-
-@example
-
- /*
- C style comments for multiline comments.
- They come before the thing to document.
- [...]
- */
-
- /**
- short description.
- Long class documentation.
- (Hungarian postfix)
-
- TODO Fix boring_member ()
- */
- class Class @{
- /**
- short description.
- long description
- */
-
- Data data_member_;
-
- /**
- short memo. long doco of member ()
- @@param description of arguments
- @@return Rettype
- */
- Rettype member (Argtype);
-
- /// memo only
- boring_member () @{
- data_member_ = 121; // ugh
- @}
- @};
-
-@end example
-
-
-Unfortunately most of the code isn't really documented that good.
-
-@unnumberedsubsec Members (2)
-
-Standard methods:
-
-@example
-
- ///check that *this satisfies its invariants, abort if not.
- void OK () const
-
- /// print *this (and substructures) to debugging log
- void print () const
-
- /**
- protected member. Usually invoked by non-virtual XXXX ()
- */
- virtual do_XXXX ()
-
- /**add some data to *this.
- Presence of these methods usually imply that it is not feasible to this
- via a constructor
- */
- add (..)
-
- /// replace some data of *this
- set (..)
-
-@end example
-
-@unnumberedsubsec Constructor
-
-Every class should have a default constructor.
-
-Don't use non-default constructors if this can be avoided:
-
-@example
-
- Foo f(1)
-
-@end example
-
-is less readable than
-
-@example
-
- Foo f;
- f.x = 1
-
-@end example
-
-or
-
-@example
-
- Foo f(Foo_convert::int_to_foo (1))
-
-@end example
-
-@unnumberedsec Hungarian notation naming convention
-
-Proposed is a naming convention derived from the so-called
-@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all
-uppercase, with the parts of the names separated by underscores.
-
-The hungarian notation is to be used when variables are not declared
-near usage (mostly in member variables and functions).
-
-@unnumberedsubsec Types
-
-@table @samp
-@item @code{byte}
- unsigned char. (The postfix _by is ambiguous)
-@item @code{b}
- bool
-@item @code{bi}
- bit
-@item @code{ch}
- char
-@item @code{f}
- float
-@item @code{i}
- signed integer
-@item @code{str}
- string class
-@item @code{sz}
- Zero terminated c string
-@item @code{u}
- unsigned integer
-@end table
-
-@unnumberedsubsec User defined types
-
-@example
-
- /** Slur blah. blah.
- (slur)
- */
- class Slur @{@};
- Slur* slur_p = new Slur;
-
-@end example
-
-@unnumberedsubsec Modifiers
-
-The following types modify the meaning of the prefix.
-These are preceded by the prefixes:
-
-@table @samp
-@item @code{a}
- array
-@item @code{array}
- user built array.
-@item @code{c}
- const. Note that the proper order is @code{Type const}
- i.s.o. @code{const Type}
-@item @code{C}
- A const pointer. This would be equivalent to @code{_c_l}, but since any
- "const" pointer has to be a link (you can't delete a const pointer),
- it is superfluous.
-@item @code{l}
- temporary pointer to object (link)
-@item @code{p}
- pointer to newed object
-@item @code{r}
- reference
-@end table
-
-@unnumberedsubsec Adjective
-
-Adjectives such as global and static should be spelled out in full.
-They come before the noun that they refer to, just as in normal english.
-
-@example
-
-foo_global_i: a global variable of type int commonly called "foo".
-
-@end example
-
-static class members do not need the static_ prefix in the name (the
-Class::var notation usually makes it clear that it is static)
-
-@table @samp
-@item @code{loop_i}
- Variable loop: an integer
-@item @code{u}
- Temporary variable: an unsigned integer
-@item @code{test_ch}
- Variable test: a character
-@item @code{first_name_str}
- Variable first_name: a String class object
-@item @code{last_name_ch_a}
- Variable last_name: a @code{char} array
-@item @code{foo_i_p}
- Variable foo: an @code{Int*} that you must delete
-@item @code{bar_i_l}
- Variable bar: an @code{Int*} that you must not delete
-@end table
-
-Generally default arguments are taboo, except for nil pointers.
-
-The naming convention can be quite conveniently memorised, by
-expressing the type in english, and abbreviating it
-
-@example
-
- static Array<int*> foo
-
-@end example
-
-@code{foo} can be described as "the static int-pointer user-array", so you get
-
-@example
-
- foo_static_l_arr
-
-@end example
-
-
-@unnumberedsec Miscellaneous
-
-For some tasks, some scripts are supplied, notably creating patches, a
-mirror of the website, generating the header to put over cc and hh
-files, doing a release.
-
-Use them.
-
-@node Making patches, , , Top
-
-
-@unnumberedsec name
-
-
-PATCHES - track and distribute your code changes
-
-This page documents how to distribute your changes to GNU lilypond
-
-We would like to have unified context diffs with full pathnames. A
-script automating supplied with Lily.
-
-Distributing a change normally goes like this:
-
-@itemize @bullet
-@item make your fix/add your code
-@item Add changes to CHANGES, and add yourself to Documentation/topdocs/AUTHORS.texi
-@item generate a patch,
-@item e-mail your patch to one of the mailing lists
- gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org
-@end itemize
-
-Please do not send entire files, even if the patch is bigger than the
-original. A patch makes it clear what is changed, and it won't
-overwrite previous (not yet released) changes.
-
-@unnumberedsec Generating a patch
-
-Simple version: run
-
-@example
- make -C lilypond-x.y.z/ distclean
- make -C lilypond-x.y.z.NEW/ distclean
- diff -urN lilypond-x.y.z/ lilypond-x.y.z.NEW/
-@end example
-
-Complicated (but automated) version:
-
-In @file{VERSION}, set MY_PATCH_LEVEL:
-
-@example
-
- VERSION:
- ...
- MY_PATCH_LEVEL=jcn1
-
-@end example
-
-In @file{CHANGES}, enter a summary of changes:
-
-@example
- pl 0.1.73.jcn1
- - added PATCHES.texi
-@end example
-
-Then, from the top of Lily's source tree, type
-
-@example
- make release
-@end example
-
-These handy python scripts assume a directory structure which looks
-like:
-
-@example
-
- lilypond -> lilypond-x.y.z # symlink to development directory
- lilypond-x.y.z/ # current development
- patches/ # patches between different releases
- releases/ # .tar.gz releases
-
-@end example
-
-(Some scripts also assume this lives in @file{$HOME/usr/src}).
-
-
-@unnumberedsec Applying patches
-
-
-If you're following LilyPond development regularly, you probably want to
-download just the patch for each subsequent release.
-After downloading the patch (into the patches directory, of course), simply
-apply it:
-
-@example
-
- gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E
-
-@end example
-
-and don't forget to make automatically generated files:
-
-@example
-
- autoconf footnote(patches don't include automatically generated files,
- i.e. file(configure) and files generated by file(configure).)
-
- configure
-
-@end example
-
-
-@bye
-
-
+++ /dev/null
-%-*-LaTeX-*-
-
-\documentclass{article}
-\usepackage{a4}
-\def\postMudelaExample{\setlength{\parindent}{1em}}
-\title{LilyPond, a Music Typesetter}
-\author{HWN}
-\usepackage{musicnotes}
-\usepackage{graphics}
-
-
-\begin{document}
-\maketitle
-
-[THIS IS WORK IN PROGRESS. THIS IS NOT FINISHED]
-
-% -*-LaTeX-*-
-\section{Introduction}
-
-The Internet has become a popular medium for collaborative work on
-information. Its success is partly due to its use of simple, text-based
-formats. Examples of these formats are HTML and \LaTeX. Anyone can
-produce or modify such files using nothing but a text editor, they are
-easily processed with run-of-the-mill text tools, and they can be
-integrated into other text-based formats.
-
-Software for processing this information and presenting these formats
-in an elegant form is available freely (Netscape, \LaTeX, etc.).
-Ubiquitousness of the software and simplicity of the formats have
-revolutionised the way people publish text-based information
-nowadays.
-
-In the field of performed music, where the presentation takes the form
-of sheet music, such a revolution has not started yet. Let us review
-some alternatives that have been available for transmitting sheet
-music until now:
-\begin{itemize}
-\item MIDI\cite{midi}. This format was designed for interchanging performances
- of music; one should think of it as a glorified tape recorder
- format. It needs dedicated editors, since it is binary. It does
- not provide enough information for producing musical scores: some of
- the abstract musical content of what is performed is thrown away.
-
-\item PostScript\cite{Postscript}. This format is a printer control
- language. Printed musical scores can be transmitted in PostScript,
- but once a score is converted to PostScript, it is virtually
- impossible to modify the score in a meaningful way.
-
-\item Formats for various notation programs. Notation programs either
- work with binary formats (e.g., NIFF\cite{niff-web}), need specific
- platforms (e.g., Sibelius\cite{sibelius}), are proprietary or
- non-portable tools themselves (idem), produce inadequate output
- (e.g., MUP\cite{mup}), are based on graphical content (e.g.,
- MusixTeX\cite{musixtex1}), limit themselves to specific subdomains
- (e.g., ABC\cite{abc2mtex}), or require considerable skill and
- knowledge to use (e.g., SCORE\cite{score})
-
-\item SMDL\cite{smdl-web}. This is a very rich ASCII format, that is
- designed for storing many types of music. Unfortunately, there is
- no implementation of a program to print music from SMDL available.
- Moreover, SMDL is so verbose, that it is not suitable for human
- production.
-
-\item TAB\cite{tablature-web}. Tab (short for tablature) is a popular
- format, for interchanging music over e-mail, but it can only be used
- for guitar music.
-\end{itemize}
-
-In summary, sheet music is not published and edited on a wide scale
-across the internet because no format for music
-interchange exists that is:
-\begin{itemize}
-\item open, i.e., with publically available specifications.
-\item based on ASCII, and therefore suitable for human consumption and
- production.
-\item rich enough for producing publication quality sheet music from
- it.
-\item based on musical content (unlike, for example, PostScript), and
- therefore suitable for making modifications.
-\item accompanied by tools for processing it that are freely available
- across multiple platforms.
-\end{itemize}
-
-
-With the creation of LilyPond, we have tried to create both a
-convenient format for storing sheet music, and a portable,
-high-quality implementation of a compiler, that compiles the input
-into a printable score. You can find a small example of LilyPond
-input along with output in Figure~\ref{fig:intro-fig}.
-%
-\begin{figure}[htbp]
- \begin{center}
-\begin[verbatim]{mudela}
- \score {
- \notes
- \context GrandStaff <
- \transpose c'' { c4 c4 g4 g4 a4 a4 g2 }
- { \clef "bass"; c4 c'4
- \context Staff <e'2 {\stemdown c'4 c'4}> f'4 c'4 e'4 c'4 }
- >
- \paper {
- linewidth = -1.0\cm ;
- }
- }
-\end{mudela}
- \caption{A small example of LilyPond input}
- \label{fig:intro-fig}
- \end{center}
-\end{figure}
-%
-
-
-The input language encodes musical events (such as notes and rests) on
-the basis of their time-ordering. For example, the grammar includes
-constructs that specify that notes start simultaneous and that notes
-are to be played in sequence. In this encoding some context that is
-present in sheet music is lost.
-
-The compiler reconstructs the notation from the encoded music. Its
-operation comprises four different steps (see
-Figure~\ref{fig:intro-steps}).
-
-\begin{description}
-\item[Parsing] During parsing, the input is converted in a syntax tree.
-
-\item[Interpreting] In the \emph{interpreting} step, it is determined
- which symbols have to be printed. Objects that correspond to
- notation (\emph{Graphical objects}) are created from the syntax tree
- in this phase. Generally speaking, for every symbol printed there is
- one graphical object. These objects are incomplete: their position
- and their final shape is unknown.
-
- The context that was lost by encoding the input in a language is
- reconstructed during this conversion.
-\item[Formatting] The next step is determing where symbols are to be
- placed, this is called \emph{formatting}.
-\item[Outputting]
- Finally, all Graphical objects are outputted as PostScript or \TeX\ code.
-\end{description}
-
-\def\staffsym{\vbox to 16pt{
- \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
- \vfil
- \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
- \vfil
- \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
- \vfil
- \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
- \vfil
- \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
-}}
-
-\def\vspacer{\vbox to 20pt{\vss}}
-\begin{figure}[h]
-\def\spacedhbox#1{\hbox{\ #1\ }}
-\begin{eqnarray*}
- {\spacedhbox{Input}\atop \hbox{\texttt{\{c8 c8\}}}} {\spacedhbox{Parsing}\atop\longrightarrow}
- {\spacedhbox{Syntax tree}\atop\spacedhbox{\textsf{Sequential(Note,Note)}}}
- {\spacedhbox{Interpreting}\atop\longrightarrow}\\
- \vspacer\\
- {\spacedhbox{Graphic objects}\atop\spacedhbox{\texttrebleclef \textquarterhead\texteighthflag\textquarterhead\texteighthflag \staffsym }}
- {\spacedhbox{Formatting}\atop\longrightarrow}
- {\spacedhbox{Formatted objects}\atop\hbox{
- \mudela{c''8 c''8}
- }}\\
-\vspacer\\
- {\spacedhbox{Outputting}\atop\longrightarrow}
- {\spacedhbox{PostScript code}\atop\hbox{\texttt{\%!PS-Adobe}\ldots}}
-\end{eqnarray*}
- \caption{Parsing, Interpreting, Formatting and Outputting}
- \label{fig:intro-steps}
-\end{figure}
-
-
-The second step, the interpretation phase of the compiler, can be
-manipulated as a separate entity: the interpretation process is
-composed of many separate modules, and the behaviour of the modules is
-parameterised. By recombining these interpretation modules,
-and changing parameter settings, the same piece of music can be
-printed differently, as is shown in Figure~\ref{fig:intro-interpret}.
-
-This makes it easy to extend the program. Moreover, this enables the
-same music to be printed in different versions, e.g., in a conductors
-score and in extracted parts.
-
-
-\begin{figure}[h]
- \begin{center}
- \begin{mudela}
- \score {
- \notes
- \context GrandStaff <
- \transpose c'' { c4 c4 g4 g4 a4 a4 g2 }
- { \clef "bass"; c4 c'4
- \context Staff <e'2 {\stemdown c'4 c'4}> f'4 c'4 e'4 c'4 }
- >
- \paper {
- linewidth = -1.0\cm ;
- \translator {
- \VoiceContext
- \remove "Stem_engraver";
- }
- \translator {
- \StaffContext
- numberOfStaffLines = 3;
- }
- }
- }
- \end{mudela}
- \caption{The interpretation phase can be manipulated: the same
- music as in Figure~\ref{fig:intro-fig} is interpreted
- differently: three staff lines and no stems.}
- \label{fig:intro-interpret}
- \end{center}
-\end{figure}
-
-
-
-\section{Preliminaries}
-
-To understand the rest of the article, it is necessary to know
-something about music notation and music typography. Since both
-communicate music, we will explain some characteristics of instruments
-and western music that motivate some notational constructs.
-
-\subsection{Music}
-
-Music notation is meant to be read by human performers. They sing or
-play instruments that can produce sounds of different pitches. These
-sounds are called \emph{notes}. Additionally, the sounds can be
-articulated in differents ways, e.g., staccato (short and separated)
-or legato (fluently bound together). The loudness of the notes can
-also be varied. Changes in loudness are called \emph{dynamics}.
-
-Silence is also an element of music. The musical terminology for
-silence within music is \emph{rest}.
-
-The basic unit of pitch is the \emph{octave}. The octave corresponds
-to a frequency ratio of 1:2. For example the pitch denoted by a'
-(frequency: 440 hertz) is one octave lower than a'' (frequency: 880
-hertz). Various instruments have a limited \emph{pitch range}, for
-example, a trumpet has a range of about 2.5 octaves. Not all
-instruments have ranges in the same register: a tuba also has a range
-of 2.5 octaves, but the range of the tuba is much lower.
-
-Musicology has a confusing mix of relative and absolute measures for
-pitches: the term `octave' refers to both a difference between two
-pitches (the frequency ratio of 1:2), and to a range of pitches. For
-example, the term `[eengestreept] octave' refers to the pitch range
-between 261.6 Hz and 523.3 Hz.
-
-
-The octave is divided into smaller pitch steps. In modern western
-music, every octave is divided into twelve approximately equidistant
-pitch steps, and each step is called a \emph{semitone}. Usually, the
-pitches in a musical piece come from a smaller subset of these twelve
-possible pitches. This smaller subset along with the musical
-functions fo the pitches is called the
-\emph{tonality}\footnote{Tonality also refers to the relations between
- and functions of certain pitches. Since these do not have any
- impact on notation, we ignore this} of the piece.
-
-
-The standard tonality that forms the basis of music notation
-(the key of C major) is a set of seven pitches within every octave.
-Each of these seven is denoted by a name. In English, these are names
-are (in rising pitch) denoted by c, d, e, f, g, a and b. Pitches that
-are a semitone higher or lower than one of these seven can be
-represented by suffixing the name with `sharp' or `flat'
-respectively (this is called an \emph{chromatic alteration}).
-
-A pitch therefore can be fully specified by a combination of the
-octave number, the note name and a chromatic alteration.
-Figure~\ref{fig:intro-pitches} shows the relation between names and
-frequencies.
-
-
-
-
-\begin{figure}[h]
- \begin{center}
- [te doen]
- \end{center}
- \caption{Pitches in western music. The octave number is denoted
- by a superscript.}
- \label{fig:intro-pitches}
-\end{figure}
-
-
-Many instruments can produce more than one note at the same time, e.g.
-pianos and guitars. When more notes are played simultaneously, they
-form a so-called \emph{chord}.
-
-The unit of duration is the \emph{beat}. When playing, the tempo is
-determined by setting the number of beats per minute. In western
-music, beats are often stressed in a regular pattern: for example
-Waltzes have a stress pattern that is strong-weak-weak, i.e. every
-note that starts on a `strong' beat is louder and has more pronounced
-articulation. This stress pattern is called \emph{meter}.
-
-\subsection{Music notation}
-
-Music notation is a system that tries to represent musical ideas
-through printed symbols. Music notation has no precise definition,
-but most conventions have described in reference manuals on music
-notation\cite{read-notation}.
-
-In music notation, sounds and silences are represented by symbols that
-are called note and rest respectively.\footnote{These names serve a
- double purpose: the same terms are used to denote the musical
- concepts.} The shape of notes and rests indicates their duration
-(See figure~\ref{noteshapes}) relative to the whole note.
-
-
-\begin{figure}[h]
- \begin{center}
-\begin{mudela}
- \score {
- \notes \transpose c''{ c\longa*1/4 c\breve*1/2 c1 c2 c4 c8 c16 c32 c64 }
- \paper {
- \translator {
- \StaffContext
- \remove "Staff_symbol_engraver";
- \remove "Time_signature_engraver";
-% \remove "Bar_engraver";
- \remove "Clef_engraver";
- }
-linewidth = -1.;
- }
-}
-\end{mudela}
-\begin{mudela}
- \score {
- \notes \transpose c''\context Staff { r\longa*1/4 r\breve*1/2 r1 r2 r4 r8 r16 r32 r64 }
- \paper {
- \translator {
- \StaffContext
- \remove "Staff_symbol_engraver";
- \remove "Time_signature_engraver";
-% \remove "Bar_engraver";
- \remove "Clef_engraver";
- }
- linewidth = -1.;
- }
-}
-\end{mudela}
- \caption{Note and rest shapes encode the length. At the top notes
- are shown, at the bottom rests. From left to right a quadruple
- note (\emph{longa}), double (\emph{breve}), whole, half,
- quarter, eigth, sixteenth, thirtysecond and sixtyfourth. Each
- note has half of the duration of its predecessor.}
- \label{fig:noteshapes}
-\end{center}
-\end{figure}
-
-
-Notes are printed in a grid of horizontal lines called \emph{staff} to
-denote their pitch: each line represents the pitch of from the
-standard scale (c, d, e, f, g, a, b). The reference point is the
-\emph{clef}, eg., the treble clef marks the location of the $g^1$
-pitch. The notes are printed in their time order, from left to right.
-
-
-\begin{figure}[h]
- \begin{center}
- \begin{mudela}
- \score { \notes {
- a4 b c d e f g a \clef bass;
- a4 b c d e f g a \clef alto;
- a4 b c d e f g a \clef treble;
- }
- \paper { linewidth = 15.\cm; }
- }
- \end{mudela}
- \caption{Pitches ranging from $a, b, c',\ldots a'$, in different
- clefs. From left right the bass, alto and treble clef are
- featured.}
- \label{fig:pitches}
- \end{center}
-\end{figure}
-
-The chromatic alterations are indicated by printing a flat sign or a
-sharp sign in front of the note head. If these chromatic alterations
-occur systematically (if they are part of the tonality of the piece),
-then this indicated with a \emph{key signature}. This is a list of
-sharp/flat signs which is printed next to the clef.
-
-Articulation is notated by marking the note shapes wedges, hats and
-dots all indicate specific articulations. If the notes are to be
-bound fluently (legato), the note shapes are encompassed by a smooth
-curve called \emph{slur},
-
-\begin{figure}[h]
- \begin{center}
- \begin{mudela}
- c'4-> c'4-. g'4 ( b'4 ) g''4
- \end{mudela}
- \caption{Some articulations. From left to right: extra stress
- (\emph{marcato}), short (staccato), slurred notes (legato).}
- \label{fig:articulation}
- \end{center}
-\end{figure}
-
-
-
-Dynamics are notated in two ways: absolute dynamics are indicated by
-letters: \textbf{f} (from Italian ``forte'') stands for loud,
-\textbf{p} (from Italian ``piano'') means soft. Gradual changes in
-loudness are notated by (de)crescendos. These are hairpin like shapes
-below the staff.
-
-\begin{figure}[h]
- \begin{center}
- \begin{mudela}
- g'4\pp \< g'4 \! g'4 \ff \> g'4 g' \! g'\ppp
- \end{mudela}
- \caption{Dynamics: start very soft (pp), grow to loud (ff) and
- decrease to extremely soft (ppp)}
- \label{fig:dynamics}
- \end{center}
-\end{figure}
-
-
-The meter is indicated by barlines: every start of the stress pattern
-is preceded by a vertical line, the \emph{bar line}. The space
-between two bar lines is called measure. It is therefore the unit of
-the rhythmic pattern.
-
-The time signature also indicates what kind of rhythmic pattern is
-desired. The time signature takes the form of two numbers stacked
-vertically. The top number is the number of beats in one measure, the
-bottom number is the duration (relative to the whole note) of the note
-that takes one beat. Example: 2/4 time signature means ``two beats
-per measure, and a quarter note takes one beat''
-
-Chords are written by attaching multiple note heads to one stem. When
-the composer wants to emphasize the horizontal relationships between
-notes, the simultaneous notes can be written as voices (where every
-note head has its own stem). A small example is given in
-Figure~\ref{fig:simultaneous}.
-
-\begin{figure}[h]
- \begin{center}
- \begin{mudela}
- \relative c'' {\time 2/4; <c4 e> <d f>
- \context Staff < \context Voice = VA{
- \stemdown
- c4 d
- b16 b b b b b b b }
- \context Voice = VB {
- \stemup e4 f g8 g4 g8 } >
- }
- \end{mudela}
- \caption{Notes sounding together. Chord notation (left, before
- the bar line) emphasizes vertical relations, voice notation
- emphasizes horizontal relations. Separate voices needn't have
- synchronous rhythms (third measure).
- }
- \label{fig:simultaneous}
- \end{center}
-\end{figure}
-
-Separate voices do not have to share one rhythmic pattern---this is
-also demonstrated in Figure~\ref{fig:simultaneous}--- they are in a sense%vaag
-independent. A different way to express this in notation, is by
-printing each voice on a different staff. This is customary when
-writing for piano (both left and right hand have a staff of their own)
-and for ensemble (every instrument has a staff of its own).
-
-
-
-\subsection{Music typography}
-
-Music typography is the art of placing symbols in esthetically
-pleasing configuration. Little is explicitly known about music
-typography. There are only a few reference works
-available\cite{ross,wanske}. Most of the knowledge of this art has
-been transmitted verbally, and was subsequently lost.
-
-The motivation behind choices in typography is to represent the idea
-as clearly as possible. Among others, this results in the following
-guidelines:
-\begin{itemize}
-\item The printed score should use visual hints to accentuate the
- musical content
-\item The printed score should not contain distracting elements, such
- as large empty regions or blotted regions.
-\end{itemize}
-
-An example of the first guideline in action is the horizontal spacing.
-The amount of space following a note should reflect the duration of
-that note: short notes get a small amount of space, long notes larger
-amounts. Such spacing constraints can be subtle, for the
-``amount of space'' is only the impression that should be conveyed; there
-has to be some correction for optical illusions. See
-Figure~\ref{fig:spacing}.
-
-\begin{figure}[h]
- \begin{center}
- \begin{mudela}
- \relative c'' { \time 3/4; c16 c c c c8 c8 | f4 f, f' }
- \end{mudela}
- \caption{Spacing conveys information about duration. Sixteenth
- notes at the left get less space than quarter notes in the
- middle. Spacing is ``visual'', there should be more space
- after the first note of the last measure, and less after second. }
- \label{fig:spacing}
- \end{center}
-\end{figure}
-
-Another example of music typography is clearly visible in collisions.
-When chords or separate voices are printed, the notes that start at
-the same time should be printed aligned (ie., with the same $x$
-position). If the pitches are close to each other, the note heads
-would collide. To prevent this, some notes (or note heads) have to be
-shifted horizontally. An example of this is given in
-Figure~\ref{fig:collision}.
-\begin{figure}[h]
- \begin{center}
- [todo]
- \caption{Collisions}
- \label{fig:collision}
- \end{center}
-\end{figure}
-
-\bibliographystyle{hw-plain}
-\bibliography{engraving,boeken,colorado,computer-notation,other-packages}
-
-\section{Requirements}
-
-
-\section{Approach}
-
-\subsection{Input}
-
-The input format consists of combining a symbolic representation of
-music with style sheet that describes how the symbolic presentation
-can converted to notation. The symbolic representation is based on a
-context free language called \textsf{music}. Music is a recursively
-defined construction in the input language. It can be constructed by
-combining lists of \textsf{music} sequentially or parallel or from
-terminals like notes or lyrics.
-
-The grammar for \textsf{music} is listed below. It has been edited to
-leave out the syntactic and ergonomic details.
-
-\begin{center}
- \begin{tabular}{ll}
-Music: & SimpleMusic\\
- & $|$ REPEATED int Music ALTERNATIVE MusicList\\
- & $|$ SIMULTANEOUS MusicList\\
- & $|$ SEQUENTIAL MusicList\\
- & $|$ CONTEXT STRING '=' STRING Music\\
- & $|$ TIMES int int Music \\
- & $|$ TRANSPOSE PITCH Music \\
-SimpleMusic: & $|$ Note\\
- & $|$ Lyric\\
- & $|$ Rest\\
- & $|$ Chord\\
- & $|$ Command\\
-Command: & METERCHANGE\\
- & $|$ CLEFCHANGE\\
- &$|$ PROPERTY STRING '=' STRING\\
-Chord: &PitchList DURATION\\
-Rest: &REST DURATION\\
-Lyric: &STRING DURATION\\
-Note: &PITCH DURATION\\
-\end{tabular}
-\end{center}
-
-The terminals are both purely musical concepts that have a duration,
-and take a non-zero amount of musical time, like notes and lyrics, and
-commands that behave as if they have no duration.\footnote{The
- PROPERTY command is a generic mechanism for controlling the
- interpretation, i.e. the musical style sheets. See [forward ref]}
-
-The nonterminal productions can
-\begin{itemize}
-\item Some productions combine multiple elements: one can specify that
- element are to be played in sequence, simultaneously or repetitively.
-\item There are productions for transposing music, and for dilating
- durations of music: the TIMES production can be used to encode a
- triplet.\footnote{A triplet is a group of three notes marked by a
- bracket, that are played 3/2 times faster.}
-\item
- There are productions that give directions to the interpretation
- engine (the CONTEXT production)
-\end{itemize}
-
-
-\section{Context in notation}
-
-Music notation relies heavily on context. Notational symbols do not
-have meaning if they are not surrounded by other context elements. In
-this section we give some examples how the reader uses this context do
-derive meaning of a piece of notation. We will focus on the prime
-example of context: the staff.
-
-A staff is the grid of five horizontal lines, but it contains more components :
-\begin{itemize}
-\item A staff can have a key signature (printed at the left)
-\item A staff can have a time signature (printed at the left)
-\item A staff has bar lines
-\item A staff has a clef (printed at the left)
-\end{itemize}
-
-It is still possible to print notes without these components, but one
-cannot determine the meaning of the notes.
-\begin{mudela}
-\score{
-\notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
-\paper {
- linewidth = -1.;
- \translator {
- \StaffContext
- \remove "Time_signature_engraver";
-% \remove "Bar_engraver";
- \remove "Staff_symbol_engraver";
- \remove "Clef_engraver";
- \remove "Key_engraver";
- }
- }
-}
-\end{mudela}
-
-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 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. Adding barlines helps with finding the strong
-and weak beats.
-\begin{mudela}
-\score {
- \notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
- \paper{
- linewidth = -1.;
-\translator{
- \StaffContext
- \remove "Staff_symbol_engraver";
- \remove "Clef_engraver";
- \remove "Key_engraver";}
- }
- }
-\end{mudela}
-
-It is impossible to deduce the exact pitch of the notes. One needs a
-clef to do so. Staff lines help the eye in determining the vertical
-position of a note wrt. to the clef.
-\begin{mudela}
-\score {
- \notes \relative c' {\clef alto; \time 2/4; g'4 c,4 a'4 f4 e c d2 }
- \paper {
- linewidth = -1.;
- }
-}
-\end{mudela}
-
-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!
-
-
-\section{Interpretation context}
-
-Context (clef, time signature etc.) determines the relationship
-between musical and its notation in notes. Because LilyPond writes
-notation, context works the other way around for LilyPond: with
-context a piece of music can be converted to notation.
-
-A reader remembers this context while reading the notation from left
-to right. By analogy, LilyPond constructs this context while
-constructing notes from left to right. This is what happens in the
-``Interpretation'' phase from~\ref{fig:intro-fig}. In LilyPond, the
-state of this context is a set of variables with their values; A staff
-context contains variables like
-
-\begin{itemize}
-\item current clef
-\item current time signature
-\item current key
-\end{itemize}
-
-These variables determine when and how clefs, time signatures, bar
-lines and accidentals are printed.
-
-
-Staff is not the only form of context in notation. In polyphonic
-music, the stem direction shows which notes form a voice: all notes of
-the same voice have stems pointing in the same direction. The value
-of this variable determines the appearance of the printed stems.
-
-In LilyPond ``Notation context'' is abstracted to a data structure
-that is used, constructed and modified during the interpretation
-phase. It contains context properties, and is responsible for
-creating notational elements: the staff context creates symbols for
-clefs, time signatures and key signatures. The Voice context creates
-stems, note heads.
-
-For the fragment of polyphonic music below,
-\begin{mudela}
- \context Staff { c'4 < { \stemup c'4 } \context Voice = VB { \stemdown a4 } > }
-\end{mudela}
-A staff context is created. Within this staff context (which printed
-the clef), a Voice context is created, which prints the first note.
-Then, a second Voice context is created, with stem direction set to
-``up'', and the direction for the other is set to down. Both Voice
-contexts are still part of the same Staff context.
-
-In the same way, multiple staff scores are created: within the score
-context, multiple staff contexts are created. Every staff context
-creates the notation associated with a staff.
-
-\section{Discussion}
-
-
-
-\end{document}
-
-The complexity of music notation was tackled by adopting a modular
-design: both the formatting system (which encodes the esthetic rules of
-notation), and the interpretation system (which encodes the semantic
-rules) are highly modular.
-
-
-The difficulty in creating a format for music notation is rooted in
-the fact that music is multi dimensional: each sound has its own
-duration, pitch, loudness and articulation. Additionally, multiple
-sounds may be played simultaneously. Because of this, there is no
-obvious way to ``flatten'' music into a context-free language.
-
-The difficulty in creating a printing engine is rooted in the fact
-that music notation complicated: it is very large graphical
-``language'' with many arbitrary esthetic and semantic conventions.
-Building a system that formats full fledged musical notation is a
-challenge in itself, regardless of whether it is part of a compiler or
-an editor.
-
-The fact that music and its notation are of a different nature,
-implies that the conversion between input notation is non-trivial.
-
-In LilyPond we solved the above problem in the following way:
-
+++ /dev/null
-
-\input lilyponddefs
-
-\def\fetdef#1#2{%
- \def#1{\hbox{\char#2}}}
-
-% huh? from where
-\input feta20.sty
-
-\font\fetasixteenfont=feta16
-\font\fetaelevenfont=feta11
-\def\fetafont{\fetasixteenfont}
-
-\newdimen\ild
-\ild=4pt
-\newdimen\stemthick
-\stemthick=0.4pt
-
-\def\eighthstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt\raise
- 3.5ex\hbox{\eighthflag}}}
-\def\texteighthflag{{\fetafont\raise 0ex\hbox{\fetafont\eighthflag}}}
-\def\textdeighthflag{{\fetafont\raise 0ex\hbox{\deighthflag}}}
-
-\def\texteighthnote{{\hbox{\hbox{\fetafont\quartball}\kern
- -0.5\stemthick\eighthstem}}}
-\def\quarterstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt}}
-\def\textquarterstem{\quarterstem}
-\def\textchord{{\hbox{\fetafont\lower.5ex\hbox to
- 0pt{\textquarterhead}\raise.5ex\hbox{\textquarterhead}\kern
- -0.5\stemthick\eighthstem}}}
-\def\textbassclef{\hbox{\fetafont\bassclef}}
-\def\texttrebleclef{\hbox{\fetafont\trebleclef}}
-\def\textslur{\embeddedps{9.378744 -3.171539 3.923099 -3.171539 0.000000 0.000000 12.800000 0.000000 3.672177 -3.672177 9.127823 -3.672177 12.800000 0.000000 0.000000 0.000000 draw_slur}}
-
-\def\textmarcato{{\fetafont\raise 1ex\hbox{\hskip 1ex\sforzatoaccent}}}
-
-
-\def\textquarterhead{\hbox{\fetafont\raise 2.5pt\hbox{\quartball}}}
-\def\texteighthstem{\hbox{\lower 5pt\hbox{\eighthstem}}}
-\def\texthalfnote{{\hbox{\hbox{\fetafont\halfball}\kern -0.5\stemthick\quarterstem}}}
-\def\textquarternote{{\hbox{\hbox{\fetafont\quartball}\kern -0.5\stemthick\quarterstem}}}
-\def\textflat{{\fetafont\raise 1ex\hbox{\flat}}}
-\def\textsharp{{\fetafont\raise1ex\hbox{\sharp}}}
+++ /dev/null
-\input texinfo @c -*-texinfo-*- vim:tw=72
-@setfilename regression-test.info
-@settitle LilyPond Regression test
-
-@c fool ls-latex
-@ignore
-@author Han-Wen Nienhuys and Jan Nieuwenhuizen
-@title LilyPond Regression test
-@end ignore
-
-@node Top, , ,
-
-@section Introduction
-
-This document tries give an brief overview of LilyPond features. When
-the text correspond with the shown notation, we consider LilyPond
-Officially BugFree (tm). This document is intended for finding bugs,
-and documenting bugfixes.
-
-@section Notes and rests
-
-Rests. Note that the dot of 8th, 16th and 32nd rests rest should be
-next to the top of the rest. All rests except the whole rest are
-centered on the middle staff line.
-
-@mudelafile{rest.fly}
-
-Note head shapes are settable. The stem endings should be adjusted
-per note head. If you want different note head styles on one stem,
-you must create a special context called Thread.
-
-@mudelafile{noteheadstyle.ly}
-
-Noteheads can have dots, and ---although this is bad style in duple
-meters--- rests can too. Augmentation dots should never be printed on
-a staff line, but rather be shifted vertically. They should go up, but
-in case of multiple parts, the down stems have down shifted dots.
-(Wanske p. 186) In case of chords, all dots should be in a column.
-The dots go along as rests are shifted to avoid collisions.
-
-@mudelafile{dots.fly}
-
-Multiple measure rests do not collide with barlines and clefs. They
-are not expanded when you set @code{Score.SkipBars}. Although the
-multi-measure-rest is a Spanner, minimum distances are set to keep it
-colliding from barlines.
-
-@mudelafile{multi-measure-rest.ly}
-
-@section Stems
-
-Stem tremolos (official naming?) or rolls are tremolo signs that look
-like beam segments crossing stems. If the stem is in a beam, the
-tremolo must be parallel to the beam. If the stem is invisible
-(eg. on a whole note), the tremolo must be centered on the note.
-
-@mudelafile{stem-tremolo.ly}
-
-Chord tremolos look like beams, but are a kind of repeat symbol.
-To avoid confusion, chord tremolo beams do not reach the stems, but
-leave a gap. Chord tremolo beams on half notes are not ambiguous,
-as half notes cannot appear in a regular beam, and should reach the
-stems.
-
-@mudelafile{chord-tremolo.sly}
-
-Beams, stems and noteheads often have communication troubles, since
-the two systems for y dimensions (1 unit = staffspace, 1 unit = 1
-point) are mixed.
-
-Stems, beams, ties and slurs should behave similarly, when placed
-on the middle staff line. Of course stem-direction is down for high
-notes, and up for low notes.
-
-@mudelafile{stem-direction.sly}
-
-Similarly, if @code{stem_default_neutral_direction} is set to @code{-1}.
-
-@mudelafile{stem-direction-down.ly}
-
-@section Scripts
-
-The staccato dot (and all scripts with follow-into-staff set), must
-not be on staff lines.
-
-@mudelafile{staccato-pos.sly}
-
-@section Grace notes
-
-Grace notes are typeset as an encapsulated piece of music. You can
-have beams, notes, chords, stems etc. within a @code{\grace} section.
-Slurs that start within a grace section, but aren't ended are attached
-to the next normal note. Grace notes have zero duration. If there
-are tuplets, the grace notes won't be under the brace. Grace notes
-can have accidentals, but they are (currently) spaced at a fixed
-distance. Grace notes (of course) come before the accidentals of the
-main note. Grace notes can also be positioned after the main note.
-
-@mudelafile{grace.ly}
-
-
-@section Beams, slurs and other spanners
-
-Beaming is generated automatically. Beams may cross bar lines. In that
-case, line breaks are forbidden. Yet clef and key signatures are
-hidden just as with breakable bar lines.
-
-@mudelafile{beaming.ly}
-
-Beams should behave reasonably well, even under extreme circumstances.
-Stems may be short, but noteheads should never touch the beam.
-
-@mudelafile{beam-extreme.ly}
-
-Beams should always reach the middle staff line, the second beam
-counting from the note head side, should never be lower than the
-second staff line. This does not hold for grace note beams.
-
-@mudelafile{beam-position.sly}
-
-Slurs should look nice and symmetric. The curvature may increase
-only to avoid noteheads, and as little as possible.
-
-@mudelafile{slur-symmetry.ly}
-@mudelafile{slur-symmetry-1.ly}
-
-Ties are strictly horizontal. They are placed in between note heads.
-The horizontal middle should not overlap with a staffline.
-
-@mudelafile{tie.ly}
-
-Beams can be typeset over fixed distance aligned staffs, beam
-beautification doesn't really work, but knees do. Beams should be
-behave well, wherever the switching point is.
-
-@mudelafile{beam-interstaff.ly}
-
-The same goes for slurs. They behave decently when broken across
-linebreak.
-
-@mudelafile{slur-interstaff.ly}
-
-Tuplets are indicated by a bracket with a number. There should be no
-bracket if there is one beam that matches the length of the tuplet.
-The bracket does not interfere with the stafflines, and the number is
-centered in the gap in the bracket.
-
-@mudelafile{tup.ly}
-
-@section Repeats
-
-LilyPond has three modes for repeats: folded, unfolded and
-semi-unfolded. Unfolded repeats are fully written out. Semi unfolded
-repeats have the body written and all alternatives sequentially.
-Folded repeats have the body written and all alternatives
-simultaneously. If the number of alternatives is larger than the
-repeat count, the excess alternatives are ignored. If the number of
-alternatives is smaller, the first alternative is multiplied to get to
-the number of repeats.
-
-Unfolded behavior:
-
-@mudelafile{repeat-unfold.ly}
-
-Volta (Semi folded) behavior. Voltas can start on non-barline moments.
-If they don't barlines should still be shown.
-
-@mudelafile{repeat-volta.ly}
-
-Folded. This doesn't make sense without alternatives, but it works.
-
-@mudelafile{repeat-fold.ly}
-
-@section Lyrics
-
-Lyrics can be set to a melody automatically. Excess lyrics will be
-dumped. Lyrics will not be set over rests. You can have melismata
-either by setting a property melismaBusy, or by setting
-automaticMelismas (which will set melismas during slurs and ties). If
-you want a different order than first Music, then Lyrics, you must
-precook a chord of staffs/lyrics and label those. Of course
-@code{\rhythm} ignores any other rhythms in the piece. Hyphens and
-extenders do not assume anything about lyric lengths, so they continue
-to work.
-
-@mudelafile{lyric-combine.ly}
-
-@section Multiple notes
-
-Rests should not collide with beams, stems and noteheads. Rests may
-be under beams. Rests should be move by integral number of spaces
-inside the staff, and by half spaces outside. Notice that the half
-and whole rests just outside the staff get ledger lines in different
-cases.
-
-@mudelafile{rest-collision.ly}
-
-Normal collisions. We have support for polyphony, where the
-middle voices are horizontally shifted.
-
-@mudelafile{collisions.ly}
-
-The number of stafflines of a staff can be set with the property
-numberOfStaffLines. Ledger lines both on note heads and rests are
-adjusted. Barlines also are adjusted.
-
-
-@mudelafile{number-staff-lines.fly}
-
-@section Spacing
-
-In a limited number of cases, LilyPond corrects for optical spacing
-effects. In this example, space for opposite pointed stems is adjusted
-
-@mudelafile{stem-spacing.sly}
-
-If there are accidentals in the music, we add space, but the space
-between note and accidentals is less than between the notes with the
-same value. Clef changes also get extra space, but not as much as
-barlines.
-
-
-Even if a line is very tightly spaced, there will still be room
-between prefatory matter and the following notes. The space after the
-prefatory is very rigid. In contrast, the space before the barline
-must stretch like the space within the measure.
-
-Tight:
-
-@mudelafile{spacing-tight.ly}
-
-Natural:
-
-@mudelafile{spacing-natural.ly}
-
-Loose:
-
-@mudelafile{spacing-loose.ly}
-
-Adding a @code{Bar_engraver} to the LyricsVoice context makes sure that
-lyrics don't collide with barlines.
-
-@mudelafile{lyrics-bar.ly}
-
-@section Global stuff
-
-Breaks can be encouraged and discouraged using @code{\break} and
-@code{\nobreak}. They are abbrevs for @code{\penalty} commands.
-
-@mudelafile{break.ly}
-
-
-Markings that are attached to (invisible) barlines are
-delicate: the are attached to the rest of the score without the score
-knowing it. Consequently, they fall over often.
-
-@mudelafile{bar-scripts.ly}
-
-Staff margins are also markings attached to barlines. They should be
-left of the staff, and be centered vertically wrt the staff. They may
-be on normal staffs, but also on compound staffs, like the PianoStaff
-
-@mudelafile{staff-margin.ly}
-
-Breathing signs, also used for phrasing, do normally not influence
-global spacing -- only if space gets tight, notes are shifted to make
-room for the breathing sign. Breathing signs break beams running
-through their voice. In the following example, the notes in the first
-two measures all have the same distance from each other:
-
-@mudelafile{breathing-sign.ly}
-
-Fonts are available in a default set of sizes: 11, 13, 16, 20, 23 and
-26pt staffheight. Sizes of the text fonts and symbol fonts are made
-to match the staff dimensions.
-
-@mudelafile[nofly]{size11.ly}
-
-@mudelafile[nofly]{size13.ly}
-
-@mudelafile[nofly]{size16.ly}
-
-@mudelafile[nofly]{size20.ly}
-
-@mudelafile[nofly]{size23.ly}
-
-@mudelafile[nofly]{size26.ly}
-
-
-@section Clefs and Time Signatures
-
-The transparent clef should not occupy any space and with style
-@code{fullSizeChanges}, the changing clef should be typeset in full
-size. For octaviated clefs, the ``8'' should appear closely above or
-below the clef respectively. The ``8'' is processed in a convoluted
-way, so this is fragile as well.
-
-@mudelafile{clefs.ly}
-
-@ignore
-@c the input file is too long and does not test for specific bugs
-By default, time signatures are written with two numbers. With style
-``C'', 4/4 and 2/2 are written with their corresponding symbols and
-with style ``old'', 2/2, 3/2, 2/4, 3/4, 4/4, 6/4, 9/4, 4/8, 6/8 and
-9/8 are typeset with symbols, all other signatures retain the default
-layout. The style ``1'', gives single number signatures for all
-signatures.
-%
-\mu delafile{time.fly}
-@end ignore
-
-@bye
--- /dev/null
+/* XPM */
+static char *noname[] = {
+/* width height ncolors chars_per_pixel */
+"50 71 63 2",
+/* colors */
+"`` c #666664",
+"`a c #F2F2F4",
+"`b c #5E5E5C",
+"`c c #EAEAEC",
+"`d c #565654",
+"`e c #E2E2E4",
+"`f c #4E4E4C",
+"`g c #DADADC",
+"`h c #464644",
+"`i c #D2D2D4",
+"`j c #3E3E3C",
+"`k c #CACACC",
+"`l c #363634",
+"`m c #C2C2C4",
+"`n c #2E2E2C",
+"`o c #BABABC",
+"`p c #262624",
+"`q c #B2B2B4",
+"`r c #1E1E1C",
+"`s c #AAAAAC",
+"`t c #161614",
+"`u c #A2A2A4",
+"`v c #0E0E0C",
+"`w c #9A9A9C",
+"`x c #060604",
+"`y c #929294",
+"`z c #8A8A8C",
+"a` c #828284",
+"aa c #7A7A7C",
+"ab c #727274",
+"ac c #6A6A6C",
+"ad c #626264",
+"ae c #5A5A5C",
+"af c #525254",
+"ag c #4A4A4C",
+"ah c #424244",
+"ai c #3A3A3C",
+"aj c #323234",
+"ak c #2A2A2C",
+"al c #FEFEFC",
+"am c #222224",
+"an c #F6F6F4",
+"ao c #1A1A1C",
+"ap c #EEEEEC",
+"aq c #121214",
+"ar c #E6E6E4",
+"as c #0A0A0C",
+"at c #DEDEDC",
+"au c #D6D6D4",
+"av c #CECECC",
+"aw c #C6C6C4",
+"ax c #BEBEBC",
+"ay c #B6B6B4",
+"az c #AEAEAC",
+"b` c #A6A6A4",
+"ba c #9E9E9C",
+"bb c #969694",
+"bc c #8E8E8C",
+"bd c #868684",
+"be c #7E7E7C",
+"bf c #767674",
+"bg c #6E6E6C",
+"bh c #FAFAFC",
+/* pixels */
+"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
+"alalbhbhalalbhalalbhalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
+"alalalbhbhalalbhalalalalalalalalalalalalalalalalalal`o`ya``s`wbhalalalalalalalalalalalalalalalalalal",
+"bhalalalalalbhalalalalalalalalalalalalalalalalalal`a`malalalap`obb`malalalalal`cax`galalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalalalalalbcalbhalalalalalax`ialalal`gauav`u`ealalalalalalal",
+"alalalalalalalbhalalalalalalalalalalalalalalalalawar`ialalalalalalalaxapalalbaacat`i`oalalalalalalal",
+"alalbhalalalalbhalalalalalalalalalalalalalalalalazal`sbhalalalalalalalayalbh`eba`iapavalalalalalalal",
+"albhalbhalalalalalalalalalalalalalalalalalalalal`oatalb``aalalalalalal`oanazazanbhayalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalalanawal`salalbaalalalalalalalazaa`cav`oalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalapawalalaranal`i`qalalalalalalbeayazbcbcalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalal`g`oapalalalalal`yalalalalal`gbbabbhapalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalal`sanalalalalalbdalalalalalbc`obbalalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalapaaanalalalalal`qatan`ealax`sbbazalalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalal`kab`oalalalalalau`uaw`salbb`ua`bcalalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalalalayalalalalalalan`ea`axax`oba`oazaxaralalalalalalalalalalal",
+"alalalalalalalalalalapbhalalalalalalalalalaybhalalalalan`s`sazav`gaz`qbdalalazalalalalalalalalalalal",
+"alalalalalalalalalalax`u`aalalalalalalalalaraw`o`c`c`aaxaw`g`kav`sayb`ayalal`m`calalalalalalalalalal",
+"alalalalalalalalalalal`c`sbhalalalalalalalalalal`c`jb`albh`yavapazay`w`ialalalay`aalalalalalalalalal",
+"alalalalalalalalalalalalar`qbhalalalalalalalalalal`v`sav`abcaubbaw`u`salalalalalayapalalalalalalalal",
+"alalalalalalalalalalalalal`i`kalalalalalalalalalal`l`way`uau`cazazazbc`q`ialalalal`galalalalalalalal",
+"alalalalalalalalalalalalalalaw`galalalalalalan`i`m`hbe`q`oap`w`m`uax`ialax`salalalalalalalalalalalal",
+"alalalalalalalalalalalalalalal`oatalalalbh`kbaadagad```oav`i`mb`ba`ualalal`i`oalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalanaz`aalanaz`nag`ian`w`k`iar`waw`o`o`ialalalalau`ialalalalalalalalalal",
+"alalalalalalalalalalalalalalalalapba`c`zakac`aalau`calapaz`gbabb`qbhalalalalal`ualalalalalalalalalal",
+"alalalalalalalalalalalalalalalalal`ibdambd`c`aalalalal`a`yax`kb``u`aalalalalal`e`kalalalalalalalalal",
+"alalalalalalalalalalalalalalalalarbcajbf`q`kalalalalal`w`c`sbc`k`e`kalalalalalal`salalalalalalalalal",
+"alalalalalalalalalalalalalalalalawaoaibbaw`kalalalalapbaaw`gb`baalaualalalalalal`salalalalalalalalal",
+"alalalalalalalalalalalalalalal`cbgaq`y`q`o`ialalalal`wbh`sba`g`oalaralalalalalal`ualalalalalalalalal",
+"alalalalalalalbhbhalalalalalalar`v`lbfazap`qapalal`gaz`k`e`y`u`galbhalalalalalalb`alalalalalalalalal",
+"alalalalalalalalalalalalalalalbb`x`l`qayalap`u`aala`al`u`q`ebebhalbhalalalalalalb`alalalalalalalalal",
+"alalalalalalalalalalalalalalal`gao`hayazalalapb``kax`iaubeaybaalalalalalalalalalbaalalalalalalalalal",
+"alalalalalalalalalalalalalalalalbdahba`galalalatbcalbb`maxbeatalalalalalalalalalbaalalalalalalalalal",
+"alalalalalalalalalalalalalalalalau`jb``calbhalal`k`oaw`zapbfalalalalanalalalalal`salalalalalalalalal",
+"alalalalalalalalalalalalalalalal`aad`malalbbalalal`o`kbb`y`ialalalal`walalalalal`qalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalbebaalapbfalalalbhbb`c`dalalalalalagalalalalap`oalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalbb`ialalajalalalalap`w`walalalalaxaaalalalal`qalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalazalalalbf`aalalalalbaayanalalalbg`ealalalbh`qalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalaxalalalbebhalalal`c`s`saxalalal``alalalalaybhalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalal`oalalal`ealalalalbb`eaw`uawalalawalbhalataualalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalanalalalalalalalal`wb`alayb``malalal`sal`oalalalalalalalalalalalal",
+"alalalalalalalalalalalalalalalalalalalal`galalalal`q`g`wauaraz`yalalaxapalbhalalalalalalalalalalalal",
+"alalalalbhalalalalbhalalalalbhbhalalbhal`salalalal`waw`kay`kapb`al`k`galalalbhbhbhbhbhalalalalalalal",
+"albhbhalbhalalalalbhalalalalalbhalalal`i`malalbhar`sbdal`q`oalalal`walalbhalalalalalbhalalalalalalal",
+"bhalalalalalalalalalalalbhalalal`ialalanavalalalbcalbbat`g`qalbhar`qalalalalalalalalalbhbhbhbhbhbhal",
+"alalalalbhbhbhalalbhbhalalalal`mbealbhalawalalalbd`iat`oaratalal`yalbhalalalalalalalalalalalalalbhal",
+"alalbhalalalalbhalalalalbhbhal`najalal`aarbhal`s`eazalazazalal`cb`alalalbhbhbhbhbhalalalalalalalalal",
+"bhalbhalalalalbhalalalalalalbbas`naralalalalal`yalazarauayalalbaa`albhalalalalalbhalalalalalalalbhal",
+"alalalalalalalalalalbhalal`aaq`r`hbdalalalalaraz`m`aazan`mal`ebd`jalalalalalalalalbhbhbhbhbhbhalalal",
+"alalbhbhbhalalbhbhalalalalaa`vah`d`d`calbhalbaal`qal`o`obhalbhbd`ray`i`gbhalalalalalalalalalbhalbhal",
+"bhalalalalbhalalalalbhalal`v`t`lah```ualalalbaan`q`cavaxalalatbeai`hauaw`waz`kav`ialalalalalalalalal",
+"bhalalalalbhalalalalal`aap`x`tahafbb`ybdalavat`sbh`sal`qalal`c`qafam`faab`axauav`i`s`oaualalbhalbhal",
+"alalalalalalalanaxax`s`q`gasao`pbebabb`ubd`walb`al`oavapalalbhaybeagaq`n`sauaw`i`iapat`kayauapalalal",
+"bhbhbhalalav`kazarauayay`sad`r`facae`mazaubgb``sbh`m`oalalalalavbbaeai`j`oav`g`oatau`c`g`a`eb`azanal",
+"alalalat`o`e`mavayavauarawayaq`lbf`yb``e`zap`yawbd`qayalalalap`ibcad`j`jbb`i`gapal`cal`iatau`gar`o`c",
+"alal`eavalbh`g`g`g`ialanaral`b`vabbd`u`ibd`e`ual`o`ea`bbbdbcb`arb````la``uap`i`cavapalarav`catav`c`q",
+"al`eavar`aanar`gavatayavaranatasae`wbcawax`iaval`calalalalalalaybcaf`hbb`garan`g`c`g`i`eatauatau`oap",
+"al`s`a`carau`capanal`gapanbhal`s`ragbc`e`k`walalalalalalal`cap`oa`bfbgarauauan`g`i`e`c`c`a`g`cauatal",
+"al`e`qay`s`i`eanarau`matau`cauau`s`ta`bd`sawalbhalalbhalapatav`s`f`baxalanat`aananan`eawat`max`aalal",
+"bhalbhawavbh`aavar`e`gawawau`k`i`c`i`h`d`y`ealalbhalalalalapauaxb`avan`carbhan`gau`aan`iax`ebhalalal",
+"alalalalan`uawawal`g`e`e`oatavat`q`ganbb`babbhalalap`ubbb`bb`z`u`gaparbhbhalanaw`iavax`cbhalalalbhal",
+"albhalbhalalbhanax`oaw`m`i`m`m`kbhalalalap`obaavalbhan`aan`aalalalalapaxawaw`oapanbhalalalalalalbhal",
+"alalalalalalalalalalananbhanbhalalalalalalalan`gb``qawavaxau`m`o`o`s`eananalalalalalalalalalalalalal",
+"alalalalalalbhbhbhalalalalalalalalbhalbhalalalalalalbhbhanbhalalalalalalalalalalalalalalalbhalalalal",
+"albhalalalbhalalalalalalalalbhbhbhalalalbhalbhalalalalalalalbhalalalalalalalalalbhalalalbhalalalbhal",
+"alalbhbhalalalalalbhalbhalalalalalalalalbhalalbhalalalalbhalalalbhalalbhbhbhalalbhbhbhalalbhalalbhal",
+"albhalalalalalalbhalbhalbhalalalalbhalalalalbhalalalalalalalalbhalbhalalalalbhalalal`aalalalbhalalal",
+"alalalalbhbhbhalalalalalalalalbhalbhalalalalalbhbhbhbhalalbhalalalbhalalalalalap`qbb`salalalalalbhal",
+"alalalbhalalalalalalalalbhbhbhalalalbhalbhalalalalalalalbhalalalalalalalalalalae`uav`calalalbhalalal",
+"bhbhalalalalalbhalbhalalalalalalalalbhalalbhalalalalbhalalalbhalalbhbhbhalalalalalaralalalalbhalbhal"
+};
--- /dev/null
+/* XPM */
+static char *noname[] = {
+/* width height ncolors chars_per_pixel */
+"100 143 65 1",
+/* colors */
+" c #ADADAD",
+". c #A5A5A5",
+"X c #9D9D9D",
+"o c #959595",
+"O c #8D8D8D",
+"+ c #858585",
+"@ c #7D7D7D",
+"# c #757575",
+"$ c #6D6D6D",
+"% c #656565",
+"& c #5D5D5D",
+"* c #555555",
+"= c #4D4D4D",
+"- c #FCFCFC",
+"; c #FAFAFA",
+": c #454545",
+"> c #F2F2F2",
+", c #3D3D3D",
+"< c #EAEAEA",
+"1 c #353535",
+"2 c #E2E2E2",
+"3 c #2D2D2D",
+"4 c #DADADA",
+"5 c #252525",
+"6 c #D2D2D2",
+"7 c #1D1D1D",
+"8 c #CACACA",
+"9 c #151515",
+"0 c #C2C2C2",
+"q c #0D0D0D",
+"w c #BABABA",
+"e c #050505",
+"r c #B2B2B2",
+"t c #AAAAAA",
+"y c #A2A2A2",
+"u c #9A9A9A",
+"i c #929292",
+"p c #8A8A8A",
+"a c #828282",
+"s c #7A7A7A",
+"d c #727272",
+"f c #6A6A6A",
+"g c #626262",
+"h c #5A5A5A",
+"j c #525252",
+"k c #FDFDFD",
+"l c #4A4A4A",
+"z c #F5F5F5",
+"x c #424242",
+"c c #EDEDED",
+"v c #3A3A3A",
+"b c #E5E5E5",
+"n c #323232",
+"m c #DDDDDD",
+"M c #2A2A2A",
+"N c #D5D5D5",
+"B c #222222",
+"V c #CDCDCD",
+"C c #1A1A1A",
+"Z c #C5C5C5",
+"A c #121212",
+"S c #BDBDBD",
+"D c #0A0A0A",
+"F c #B5B5B5",
+"G c #020202",
+/* pixels */
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkk;kkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkk;kkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkk;kkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.lexGGj*9jkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkhkkkkkkkkwhs+kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk6 kkkkkkkkkkkVeCkkkkkkkkkkkkrsspkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkOkkkkkkkkkkkkkk2G2kkkkkkkkkdkkkkekkkkkkkkkkkkkkkk",
+"k;kkkk;kkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.Gkkkckkkkkkkkkkkk@kkkkkkkkskk:kkdokkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkw2rkkkkkkkkkkkkkkkkk1kkkkkkkdkGykuk@kkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkskk*kkkkkkkkkkkkkkkkrZkkkkkkGGtkm k%kkkkkkkkkkkkkkk",
+"kkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkjkkk$kkkkkkkkkkkkkkkkk=kkkkkkwniw kk@kkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk&kkkk3kkkkkkkkkkkkkkkkw6kkkkkk>X6kk4rkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkakkkkk=kkkkkkkkkkkkkkkk=kkkw:vNkkkk$kkkkkkkkkkkkkkkk",
+"kkkkkkkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk&k06kkkvckkkkkkkkkkkkkk+zkkqkkkkkk&kkkkkkkkkkkkkkkkk",
+"kk;;kk;kkkkkkk;kk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkukkk+kkkk,kkkkkkkkkkkkkkk%kMkkkkk.ykkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkX8kky+kkkkk:kkkkkkkkkkkkkk$kGZk2Fwykkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkNikkkkk+mkkkknckkkkkkkkkkkkk@l*kZM@vGkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk4okkkkkkkkkkkkkGkkkkkkkkkkkkkZfikXkc$Ckkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkjkkkkkkkkkkkkkkGkkkkkkkkkkkkk9ry,>kktkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk% Zkkkkkkkkkkky.kkkkkkkkkkkXu6f$kkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk<fVkkkkkkkkkkkm7kkkkkkkkkkkG0bgkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkgkkkkkkkkkkkkkb,kkkkkkkkkkxkFiDkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2GkkkkkkkkkkkkkkqkkkkkkkkkkBFkaGkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk9kkkkkkkkkkkzk.ykkkkwkkkMktaOzZkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk:9Aakkkkkkkkkkkakjkkok:kkk*.khnkDkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk60a=kkkkkkkkkkkkV:kkOk&kkCkfpp8k5kkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkktkkkkkkkkkkkkkkrkAkk*k$kb#skd:kknkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk,kkkkkkkkkkkkkkkkGkkikak7k%rcjkkXZkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkdkkkkkkkkkkkkkkp@FCkkub4SV#khOkkkk,kkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkk;kkkkkkkkkkkkkkkkkkkk%kkkkkkkkkkkkk%whkakmVFk3kfkZxkkkk@kkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkk,bt2kkkkkkkkkkkkkkkkkkksSkkkkkkkkkk#y<F<dkokkazsk3k+kkkkk:kkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkXugckkkkkkkkkkkkkkkkkkkSOddVkkkkk$kpm<>okpkknk*kh%kkkkkki4kkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkaikkkkkkkkkkkkkkkkkkkkkkk4rqZFskkk>kgk0>k%z44hk=kkkkkkk:kkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkk+ikkkkkkkkkkkkkkkkkkkkkkkkGhFFkkkk>Akskkvk*kxmZkkkkkkkkdkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkiikkkkkkkkkkkkkkkkkkkkkkk7D+0kkkk*FbNk,kkp.k*kkkkkkkkkzlkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkk>u.kkkkkkkkkkkkkkkkkkkkkkGGrF$;kkGkOkk7knkvkdkkkkkkkkkkzdkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkZoZkkkkkkkkkkkkkkkkkkkkkMM8$skk*zwkk:kkoNS@@kkkkkkkkkkkzMkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkSybkkkkkkkkkkkkkkkkkkkkfDO *kk=kwk>,kvk3kn>g$0kkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkku kkkkkkkkkkkkkkkkkkkV+G%uXkGkykk3kkfk+kjkkk*Mkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkO.kkkkkkkkkkkkkkk4o4k.G@&FS46;k4gkvkvk1gkkkkkG>kkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkiukkkkkkkkkkkkmSkSGG&GtrMFktkk9kk%kqkGckkkkkkGkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkcX kkkkkkkkkkukgGGG+;GMxZkOkkutkvk$k#xkkkkkkkk5kkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkNoVkkkkkkktjdGGsikkkGGVk+kmkBkkdkMkGhkkkkkkkkkjkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk X<kkkkk ZGG7s<kkkkv;kukcbd2kjku64Ghkkkkkkkkk6ykkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkuXkkk26oG%*t>>kkyakk;;kyk7kkxkGkGykkkkkkkkkkkMkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkphk6k9Gqx1kkkkNSkkkkkSk,kk:k2skGmkkkkkkkkkkkb&kkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk+ukGG&=k<kkkkkkkkkkkkknkkxkGk=X kkkkkkkkkkkkhkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk0SeG$tpkk6kkkkkkkkkkkGkk:kkvkGCk>kkkkkkkkkkkzakkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.;G<AnsVkgkkkkkkkkkkkpdkkxk9kblik$kkkkkkkkkkkkMkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkZkGGDknuSc6kkkkkkkkkkkGkkhkkGkAiak+kkkkkkkkkkkkgkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkiOG=qiV>6i>kkkkkkkkkk+tkkjkh;kGpkkskkkkkkkkkkkkwrkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk6kG77n:VOk#kkkkkkkkkkkGkkskkqkjx6k; kkkkkkkkkkkkk&kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk lGGxX,koykkkkkkkkkkkgbkk3k+tkGkkk$kkkkkkkkkkkkkk3kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk6kGGGFXdkbyukkkkkkkkkkCkkf;kGk41<kk@kkkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkZ%GCahFO4tcOSkkkkkkkk5kkkjkSgk9Zzkbb0kkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk<GGvC3 4pkk6i<kkkkkkN,kkOzkGkkGh>kkkpkkkkkkkkkkkkk=kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk4rGG1nyjm%kkkOakkkkkkDkkknkk1koGtkkkkokkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk ,GC,5 cZ6kkkkO@kkkk.gkkONk1kkGZkkkk+kkkkkkkkkkkkkk=kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkOyGG=l#;%2kkkkkOakkkGkkknkkGkkCfkkkk;kkkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk4GG:*OV@Zkkkkkkpiktpkk 8k56kv9;kkkkkkkkkkkkkkkkkkk,kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkcGG#s>ykkkkkkk>obGkkk7kkGkkq8kkkkkkkkkkkkkkkkkkkk7kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2CGp*0rkkkkkkkk .akkurkp+kbqokkkkkkkkkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkm#Gpd;bkkkkkkkkktukkDkkGkkxu>kkkkkkkkkkkkkkkkkkkk=kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkNGgCkFkkkkkkkkkkpXmik<,kkGSkkkkkkkkkkkkkkkkkkkkk&kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkktyGtVkkkkNkkkkkkkovkkGkkdd4kkkkkkkkNkkkkkkkkkkkkfkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkSGk.kkkkGkkkkkkk;o0kGkk9rkkkkkkkkkGkkkkkkkkkkkw8kkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkbAhkkkkkGkkkkkkkk2t3wkwx;kkkkkkkkkG2kkkkkkkkkkMkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk83MkkkkFGkkkkkkkkkuokkA*kkkkkkkkkkG&kkkkkkkkkkhkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkA=kkkkkGVkkkkkkkkkd.kGbkkkkkkkkkkGZkkkkkkkkk$;kkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk5ykkkkkGGkkkkkkkkkkfdnzkkkkkkkkkaGkkkkkkkkkkgkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkjkkkkkkrGkkkkkkkkkkkdikkkkkkkkkkGDkkkkkkkkk<akkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkklkkkkkkkG>kkkkkkkkkN&wukkkkkkkk<Gkkkkkkkkkkxkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkakkkkkkkG0kkkkkkkkkCk;ptkkkkkkkFGkkkkkkkkk6wkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkdkkkkkkkGkkkkkkkkkknkw@w8kkkkkk Gkkkkkkkkk,kkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkt4kkkkkkkGkkkkkkkkk$NkgkXS>kkkkkkGkkkkkkkkObkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkhkkkkkkkkkkkkkkkkkkGkkgkk9ykkkkkkpkkkkkkk2.kkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkykkkkkkkkkkkkkkkkk2gkjzkXkyskkkkkkkkkbkkkhkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkvkkxkk&k4@#kkkkkkkm5kk*kkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk7kkgkkfk&koZkkkkkk%kk;0kkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2kkkkkkkkkf8k1kktNkjkiXkkkkkhkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk:kkkkkkkkkekk7kk$kkhk@akkkkfkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkobkkkkkkkk4#kr+kkjkOkkXhkkk ykkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk5kkkkkkkkkCkkGkk6Zk%kkkkkkk7kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkik kkkkkkkkCkkGkkgkk%kkkkkk8pkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkpkskkkkkkkgbkOrkkgkV8kkkkkk9kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2NkkkkkkkGkkGkkNXkhkkkkkkk3kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkGkkkkkkkukkkkkkk4&kkfkk$kk$kkkkkk$kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkFGkkkkkkk+kkkkkkkqkkFSkkfkz kkkkkkqkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkGGckkkkkkukkkkkkkDkkjkk>ykdkkkkkkk7kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkhGGdkkkkkNSkkkkkk=4kkjkk*kk*kkkkkkk%kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkGGCGkkkkkkkkkkkkkGkka;kk=kk&kkkkkawikkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkAGG%Gkkkkkkkkkkkk4&kkjkkkukXckkkkmn$.kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkk>G3Gnv%kkkkkkkkkkkCkkk&kk%kk=kkkkkkg3Xkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkGGe91gGkkkkkkkkkkkCkkpkkkjkk$kkkbS.99@kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkk GGA$B%pskkkkkkkkkd4kk=kkkdkVZkkkkbbdG3kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkGGAG$Gi$v;kkkkkkkk7kk>skk+kk%kkkkkk0OG,okkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkktGBqCaha9dXkkkkkkkk&kkhkkkhkk$kkkkk<#BvG9mpsfN>kkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkGGGeD=,Chtswkkkkkk1kkkjkkkskk+kkkk6mX@:BC:kNrm3$fwitkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkGGGj5*gl$12=kkkkkk1kkNokkozkskkkkkk0y&%1GtFkykkF$kckdpftkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkGAG5en#Dwyk+7kkkkZ kkjkkkxkkgkkkkkkkF hCnGlgO.xz<ruckkko*+wkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkwtkGAG5ij#%&Vfn$3kkk,kkk3kkk*kk%kkkkkktNw v1GqqM,aV+m22ty>>4b+dyikkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkbot&h akGGG5GG*@syi06.Gkkhkkrwkk bkF2kkkkkkkwp +*=DGGjokkSjNXk tkkkk2ud$2kkkkkkkkk",
+"kkkkkkkkkkkkkkk6p3$48wNckknGG=*MfNSt.a*c#*Akkk3kkk*kk&kkkkkkkkkX@loD=Ge$apykkkNkkkm2mVVkkk8sXkkkkkkk",
+"kkkkkkkkkkkkkXi4k>0NsZk+sSrGB,Cs,lMAX46fkkGlak&kkk&kk&kkkkkkkkkpt$$,%MGh%>kkkbFrwm2k4>kbkkmkN9#kkkkk",
+"kkkkkkkkkkNvy6%SkkkbN8awiSkGeDBpl0Fdc0.k0Si;8G&kk4Vk<tkkkkkkkkm6.F%&MMGyZk dXwFSkb t;;FFk8Nk4N2Mmkkk",
+"kkkkkkkkF=Sk@2k++tkkwZ;2Zs #G,B*othug04Sk9kkk,kvd@kk@kkkkkkkkzSbwis1xhGjr9tNZ0kkkkkkkkzZcm2X;k<km&kk",
+"kkkkkkkgmkkkk bckOhwkkkmkkz;GG1qxli6VpkkVnk4VgkkkGGa*kkkkkkkkr4V%sFnvMGy+kkkkk4<kkb2kk< zyk4tS>kS2uk",
+"kkkkkk%zkkkk<800840kkkkkkkkkFGDG:O aOOkVoa.k%kkkbSk>Gn&GGBnD9uV<dy@3$BGkG22mFFbb0y2kkkkk0SrkkNy6Vkgk",
+"kkkk;#kkkkk>wkzkkNZ4kkk6VSkkkGGCps&$k$gkDk4k5kkkgkk>kkkkkkkkkkkz0bd#vGvbFkkkk4mkkZNkkkkt6kkzrkkF<k*k",
+"kkkk*kzFkbkkzkkSNNktag@6kkkkktGB3X4f@fkunkkk%kkk0kkkkkkkkkkkkk.N8uGfD@6nkkkkck>pNkk>owbkkkrNkmw;y mk",
+"kkk$kkkb<kk4mNZZZ0bkkkkkmFmkkkGG3%otorakk<knkkkkkkkkkkkkkkkkkkS@xflovf%k0XXckkzkk2oNkkk u0k6ukV<<Xkk",
+"kkk=k6kk0NSbkVmkkkkk<6kkkkkkkkkGGxjMrr>kykkAkkkkkkkkkkkkkkkkkkkwoZ+$3orkkkkkk4 Zkkkkk.0kkkbkk4kbukkk",
+"kkkhkk8Nkkb8>zckkckkbFV<ck>kkkkkGBGOj%r;#k2+kkkkkkkkkkkkkkkyw<wd&=pfy%kkFtXrkkkkou.zk;kkk>w02k.wkkkk",
+"kkkXscihna6kwkbzkkk0iVz0y8kckVykkGC7oZGky8,kkkkkkkkkkkkkkwZkkFuh=jll3kkkkkkkk<2kkkkkkkkVw;k ;hckkkkk",
+"kkkkklkkk>wr6kkk>opkk.0k2kFkO;ZbkkqGxdM8Fpkkkkkkkkkkkkkkkkk FVkNn%F5kkkkkk2tcckkkk2kVtiukSwyokkkkkkk",
+"kkkkkkXOkkkkkkkyVkkkkVSZZ kFNF48Nkk8Gl5FiakkkkkkkkkkkkkkkkkV0 dpka&kkkkkkkkkkkkwyF4kkzzkruykkkkkkkkk",
+"kkkkkkkzsykkkNpkkm4wF2w2N8<wZ2Fbk6k009G&xcickkkkkkkkkkkkkkkkkkkkhNkkkNZNrVkkk4rckkkkkkNaykkkkkkkkkkk",
+"kkkkkkkkk;g3Skkkkk VF2mrkS64kZkktS@zkkOGftrqkkkkkkkk6m2S2b@#5GqskwVk8bkkkkkkkmkkkkko$aZkkkkkkkkkkkkk",
+"kkkkkkkkkkkk6s@okkkkkkkkfF;Ny04ya8kkkkkk=G+f<kkkkkkyj&j:xfa6kkk;6zkkkkkkkkkkkkmvXyuzkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkk;fasikkkkkkzkko$Nkkkkkkkkkc&wb kkkkkkkkkkkk<kkkk;kkkkkkkkkk #afNkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkmud$# rs+@kkkkkkkkkkkkkkco15;kkkkkkkkkkkkkkkkkkkkkt%a@pkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkaxg$* o;mkkkkyojuf+=hyzkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk44d#ddN6kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk-kkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk--kkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk-k-----kkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk----k--kkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk;--kk-kkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk-kkkkkkkkkkkkkkkk",
+"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk-kkkkkkkkkkkkkkkk"
+};
+++ /dev/null
-/* XPM */
-static char *noname[] = {
-/* width height ncolors chars_per_pixel */
-"50 71 63 2",
-/* colors */
-"`` c #666664",
-"`a c #F2F2F4",
-"`b c #5E5E5C",
-"`c c #EAEAEC",
-"`d c #565654",
-"`e c #E2E2E4",
-"`f c #4E4E4C",
-"`g c #DADADC",
-"`h c #464644",
-"`i c #D2D2D4",
-"`j c #3E3E3C",
-"`k c #CACACC",
-"`l c #363634",
-"`m c #C2C2C4",
-"`n c #2E2E2C",
-"`o c #BABABC",
-"`p c #262624",
-"`q c #B2B2B4",
-"`r c #1E1E1C",
-"`s c #AAAAAC",
-"`t c #161614",
-"`u c #A2A2A4",
-"`v c #0E0E0C",
-"`w c #9A9A9C",
-"`x c #060604",
-"`y c #929294",
-"`z c #8A8A8C",
-"a` c #828284",
-"aa c #7A7A7C",
-"ab c #727274",
-"ac c #6A6A6C",
-"ad c #626264",
-"ae c #5A5A5C",
-"af c #525254",
-"ag c #4A4A4C",
-"ah c #424244",
-"ai c #3A3A3C",
-"aj c #323234",
-"ak c #2A2A2C",
-"al c #FEFEFC",
-"am c #222224",
-"an c #F6F6F4",
-"ao c #1A1A1C",
-"ap c #EEEEEC",
-"aq c #121214",
-"ar c #E6E6E4",
-"as c #0A0A0C",
-"at c #DEDEDC",
-"au c #D6D6D4",
-"av c #CECECC",
-"aw c #C6C6C4",
-"ax c #BEBEBC",
-"ay c #B6B6B4",
-"az c #AEAEAC",
-"b` c #A6A6A4",
-"ba c #9E9E9C",
-"bb c #969694",
-"bc c #8E8E8C",
-"bd c #868684",
-"be c #7E7E7C",
-"bf c #767674",
-"bg c #6E6E6C",
-"bh c #FAFAFC",
-/* pixels */
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalbhbhalalbhalalbhalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalbhbhalalbhalalalalalalalalalalalalalalalalalal`o`ya``s`wbhalalalalalalalalalalalalalalalalalal",
-"bhalalalalalbhalalalalalalalalalalalalalalalalalal`a`malalalap`obb`malalalalal`cax`galalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalbcalbhalalalalalax`ialalal`gauav`u`ealalalalalalal",
-"alalalalalalalbhalalalalalalalalalalalalalalalalawar`ialalalalalalalaxapalalbaacat`i`oalalalalalalal",
-"alalbhalalalalbhalalalalalalalalalalalalalalalalazal`sbhalalalalalalalayalbh`eba`iapavalalalalalalal",
-"albhalbhalalalalalalalalalalalalalalalalalalalal`oatalb``aalalalalalal`oanazazanbhayalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalanawal`salalbaalalalalalalalazaa`cav`oalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalapawalalaranal`i`qalalalalalalbeayazbcbcalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalal`g`oapalalalalal`yalalalalal`gbbabbhapalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalal`sanalalalalalbdalalalalalbc`obbalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalapaaanalalalalal`qatan`ealax`sbbazalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalal`kab`oalalalalalau`uaw`salbb`ua`bcalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalayalalalalalalan`ea`axax`oba`oazaxaralalalalalalalalalalal",
-"alalalalalalalalalalapbhalalalalalalalalalaybhalalalalan`s`sazav`gaz`qbdalalazalalalalalalalalalalal",
-"alalalalalalalalalalax`u`aalalalalalalalalaraw`o`c`c`aaxaw`g`kav`sayb`ayalal`m`calalalalalalalalalal",
-"alalalalalalalalalalal`c`sbhalalalalalalalalalal`c`jb`albh`yavapazay`w`ialalalay`aalalalalalalalalal",
-"alalalalalalalalalalalalar`qbhalalalalalalalalalal`v`sav`abcaubbaw`u`salalalalalayapalalalalalalalal",
-"alalalalalalalalalalalalal`i`kalalalalalalalalalal`l`way`uau`cazazazbc`q`ialalalal`galalalalalalalal",
-"alalalalalalalalalalalalalalaw`galalalalalalan`i`m`hbe`q`oap`w`m`uax`ialax`salalalalalalalalalalalal",
-"alalalalalalalalalalalalalalal`oatalalalbh`kbaadagad```oav`i`mb`ba`ualalal`i`oalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalanaz`aalanaz`nag`ian`w`k`iar`waw`o`o`ialalalalau`ialalalalalalalalalal",
-"alalalalalalalalalalalalalalalalapba`c`zakac`aalau`calapaz`gbabb`qbhalalalalal`ualalalalalalalalalal",
-"alalalalalalalalalalalalalalalalal`ibdambd`c`aalalalal`a`yax`kb``u`aalalalalal`e`kalalalalalalalalal",
-"alalalalalalalalalalalalalalalalarbcajbf`q`kalalalalal`w`c`sbc`k`e`kalalalalalal`salalalalalalalalal",
-"alalalalalalalalalalalalalalalalawaoaibbaw`kalalalalapbaaw`gb`baalaualalalalalal`salalalalalalalalal",
-"alalalalalalalalalalalalalalal`cbgaq`y`q`o`ialalalal`wbh`sba`g`oalaralalalalalal`ualalalalalalalalal",
-"alalalalalalalbhbhalalalalalalar`v`lbfazap`qapalal`gaz`k`e`y`u`galbhalalalalalalb`alalalalalalalalal",
-"alalalalalalalalalalalalalalalbb`x`l`qayalap`u`aala`al`u`q`ebebhalbhalalalalalalb`alalalalalalalalal",
-"alalalalalalalalalalalalalalal`gao`hayazalalapb``kax`iaubeaybaalalalalalalalalalbaalalalalalalalalal",
-"alalalalalalalalalalalalalalalalbdahba`galalalatbcalbb`maxbeatalalalalalalalalalbaalalalalalalalalal",
-"alalalalalalalalalalalalalalalalau`jb``calbhalal`k`oaw`zapbfalalalalanalalalalal`salalalalalalalalal",
-"alalalalalalalalalalalalalalalal`aad`malalbbalalal`o`kbb`y`ialalalal`walalalalal`qalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalbebaalapbfalalalbhbb`c`dalalalalalagalalalalap`oalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalbb`ialalajalalalalap`w`walalalalaxaaalalalal`qalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalazalalalbf`aalalalalbaayanalalalbg`ealalalbh`qalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalaxalalalbebhalalal`c`s`saxalalal``alalalalaybhalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalal`oalalal`ealalalalbb`eaw`uawalalawalbhalataualalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalanalalalalalalalal`wb`alayb``malalal`sal`oalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalal`galalalal`q`g`wauaraz`yalalaxapalbhalalalalalalalalalalalal",
-"alalalalbhalalalalbhalalalalbhbhalalbhal`salalalal`waw`kay`kapb`al`k`galalalbhbhbhbhbhalalalalalalal",
-"albhbhalbhalalalalbhalalalalalbhalalal`i`malalbhar`sbdal`q`oalalal`walalbhalalalalalbhalalalalalalal",
-"bhalalalalalalalalalalalbhalalal`ialalanavalalalbcalbbat`g`qalbhar`qalalalalalalalalalbhbhbhbhbhbhal",
-"alalalalbhbhbhalalbhbhalalalal`mbealbhalawalalalbd`iat`oaratalal`yalbhalalalalalalalalalalalalalbhal",
-"alalbhalalalalbhalalalalbhbhal`najalal`aarbhal`s`eazalazazalal`cb`alalalbhbhbhbhbhalalalalalalalalal",
-"bhalbhalalalalbhalalalalalalbbas`naralalalalal`yalazarauayalalbaa`albhalalalalalbhalalalalalalalbhal",
-"alalalalalalalalalalbhalal`aaq`r`hbdalalalalaraz`m`aazan`mal`ebd`jalalalalalalalalbhbhbhbhbhbhalalal",
-"alalbhbhbhalalbhbhalalalalaa`vah`d`d`calbhalbaal`qal`o`obhalbhbd`ray`i`gbhalalalalalalalalalbhalbhal",
-"bhalalalalbhalalalalbhalal`v`t`lah```ualalalbaan`q`cavaxalalatbeai`hauaw`waz`kav`ialalalalalalalalal",
-"bhalalalalbhalalalalal`aap`x`tahafbb`ybdalavat`sbh`sal`qalal`c`qafam`faab`axauav`i`s`oaualalbhalbhal",
-"alalalalalalalanaxax`s`q`gasao`pbebabb`ubd`walb`al`oavapalalbhaybeagaq`n`sauaw`i`iapat`kayauapalalal",
-"bhbhbhalalav`kazarauayay`sad`r`facae`mazaubgb``sbh`m`oalalalalavbbaeai`j`oav`g`oatau`c`g`a`eb`azanal",
-"alalalat`o`e`mavayavauarawayaq`lbf`yb``e`zap`yawbd`qayalalalap`ibcad`j`jbb`i`gapal`cal`iatau`gar`o`c",
-"alal`eavalbh`g`g`g`ialanaral`b`vabbd`u`ibd`e`ual`o`ea`bbbdbcb`arb````la``uap`i`cavapalarav`catav`c`q",
-"al`eavar`aanar`gavatayavaranatasae`wbcawax`iaval`calalalalalalaybcaf`hbb`garan`g`c`g`i`eatauatau`oap",
-"al`s`a`carau`capanal`gapanbhal`s`ragbc`e`k`walalalalalalal`cap`oa`bfbgarauauan`g`i`e`c`c`a`g`cauatal",
-"al`e`qay`s`i`eanarau`matau`cauau`s`ta`bd`sawalbhalalbhalapatav`s`f`baxalanat`aananan`eawat`max`aalal",
-"bhalbhawavbh`aavar`e`gawawau`k`i`c`i`h`d`y`ealalbhalalalalapauaxb`avan`carbhan`gau`aan`iax`ebhalalal",
-"alalalalan`uawawal`g`e`e`oatavat`q`ganbb`babbhalalap`ubbb`bb`z`u`gaparbhbhalanaw`iavax`cbhalalalbhal",
-"albhalbhalalbhanax`oaw`m`i`m`m`kbhalalalap`obaavalbhan`aan`aalalalalapaxawaw`oapanbhalalalalalalbhal",
-"alalalalalalalalalalananbhanbhalalalalalalalan`gb``qawavaxau`m`o`o`s`eananalalalalalalalalalalalalal",
-"alalalalalalbhbhbhalalalalalalalalbhalbhalalalalalalbhbhanbhalalalalalalalalalalalalalalalbhalalalal",
-"albhalalalbhalalalalalalalalbhbhbhalalalbhalbhalalalalalalalbhalalalalalalalalalbhalalalbhalalalbhal",
-"alalbhbhalalalalalbhalbhalalalalalalalalbhalalbhalalalalbhalalalbhalalbhbhbhalalbhbhbhalalbhalalbhal",
-"albhalalalalalalbhalbhalbhalalalalbhalalalalbhalalalalalalalalbhalbhalalalalbhalalal`aalalalbhalalal",
-"alalalalbhbhbhalalalalalalalalbhalbhalalalalalbhbhbhbhalalbhalalalbhalalalalalap`qbb`salalalalalbhal",
-"alalalbhalalalalalalalalbhbhbhalalalbhalbhalalalalalalalbhalalalalalalalalalalae`uav`calalalbhalalal",
-"bhbhalalalalalbhalbhalalalalalalalalbhalalbhalalalalbhalalalbhalalbhbhbhalalalalalaralalalalbhalbhal"
-};
+++ /dev/null
-/* XPM */
-static char *noname[] = {
-/* width height ncolors chars_per_pixel */
-"100 143 64 2",
-/* colors */
-"`` c #666664",
-"`a c #F2F2F4",
-"`b c #5E5E5C",
-"`c c #EAEAEC",
-"`d c #565654",
-"`e c #E2E2E4",
-"`f c #4E4E4C",
-"`g c #DADADC",
-"`h c #464644",
-"`i c #D2D2D4",
-"`j c #3E3E3C",
-"`k c #CACACC",
-"`l c #363634",
-"`m c #C2C2C4",
-"`n c #2E2E2C",
-"`o c #BABABC",
-"`p c #262624",
-"`q c #B2B2B4",
-"`r c #1E1E1C",
-"`s c #AAAAAC",
-"`t c #161614",
-"`u c #A2A2A4",
-"`v c #0E0E0C",
-"`w c #9A9A9C",
-"`x c #060604",
-"`y c #929294",
-"`z c #8A8A8C",
-"a` c #828284",
-"aa c #7A7A7C",
-"ab c #727274",
-"ac c #6A6A6C",
-"ad c #626264",
-"ae c #5A5A5C",
-"af c #525254",
-"ag c #4A4A4C",
-"ah c #424244",
-"ai c #3A3A3C",
-"aj c #323234",
-"ak c #2A2A2C",
-"al c #FEFEFC",
-"am c #222224",
-"an c #F6F6F4",
-"ao c #1A1A1C",
-"ap c #EEEEEC",
-"aq c #121214",
-"ar c #E6E6E4",
-"as c #0A0A0C",
-"at c #DEDEDC",
-"au c #020204",
-"av c #D6D6D4",
-"aw c #CECECC",
-"ax c #C6C6C4",
-"ay c #BEBEBC",
-"az c #B6B6B4",
-"b` c #AEAEAC",
-"ba c #A6A6A4",
-"bb c #9E9E9C",
-"bc c #969694",
-"bd c #8E8E8C",
-"be c #868684",
-"bf c #7E7E7C",
-"bg c #767674",
-"bh c #6E6E6C",
-"bi c #FAFAFC",
-/* pixels */
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalbialalalalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalbialalalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalbialalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbaag`xahauauaf`d`tafalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaealalalalalalalal`oaeaabealalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`ib`alalalalalalalalalalalaw`xaoalalalalalalalalalalalal`qaaaa`zalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbdalalalalalalalalalalalalalal`eau`ealalalalalalalalalabalalalal`xalalalalalalalalalalalalalalalal",
-"albialalalalbialalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbaaualalalapalalalalalalalalalalalalbfalalalalalalalalaaalal`halalabbcalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`o`e`qalalalalalalalalalalalalalalalalal`lalalalalalalalabalau`ual`walbfalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaaalal`dalalalalalalalalalalalalalalalal`qaxalalalalalalauau`salatb`al``alalalalalalalalalalalalalalal",
-"alalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalafalalalbhalalalalalalalalalalalalalalalalal`falalalalalal`oaj`y`ob`alalbfalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`balalalal`nalalalalalalalalalalalalalalalal`o`ialalalalalal`abb`ialal`g`qalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalala`alalalalal`falalalalalalalalalalalalalalalal`falalal`o`haiavalalalalbhalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`bal`m`ialalalaiapalalalalalalalalalalalalalalbeanalal`valalalalalal`balalalalalalalalalalalalalalalalal",
-"alalbibialalbialalalalalalalbialalbialalalalalalalalalalalalalalalalalalalalalalalalalalalalal`walalalbealalalal`jalalalalalalalalalalalalalalal``alakalalalalalba`ualalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbb`kalal`ubealalalalal`halalalalalalalalalalalalalalbhalauaxal`eaz`o`ualalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalav`yalalalalalbeatalalalalajapalalalalalalalalalalalalalbfag`dalaxakbfaiaualalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`gbcalalalalalalalalalalalalalaualalalalalalalalalalalalalaxac`yalbbalapbhaoalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalafalalalalalalalalalalalalalalaualalalalalalalalalalalalal`t`q`u`j`aalal`salalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal``b`axalalalalalalalalalalal`ubaalalalalalalalalalalalbb`w`iacbhalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`cacawalalalalalalalalalalalat`ralalalalalalalalalalalau`maradalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaladalalalalalalalalalalalalalar`jalalalalalalalalalalahalaz`yasalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`eaualalalalalalalalalalalalalal`valalalalalalalalalalamazala`aualalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`talalalalalalalalalalalanalba`ualalalal`oalalalakal`sa`bdanaxalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`h`taqa`alalalalalalalalalalala`alafalalbcal`halalal`dbaalaeajalasalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`i`ma``falalalalalalalalalalalalaw`halalbdal`balalaoalac`z`z`kal`palalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`salalalalalalalalalalalalalal`qalaqalal`dalbhalarbgaaalab`halalajalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`jalalalalalalalalalalalalalalalalaualal`yala`al`ral```qapafalalbbaxalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalabalalalalalalalalalalalalalal`zbfazaoalal`war`gayawbgalaebdalalalal`jalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalbialalalalalalalalalalalalalalalalalalalal``alalalalalalalalalalalalal```oaeala`alatawazal`nalacalaxahalalalalbfalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalal`jar`s`ealalalalalalalalalalalalalalalalalalalaaayalalalalalalalalalalbg`u`caz`cabalbcalala`anaaal`nalbealalalalal`halalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalbb`wadapalalalalalalalalalalalalalalalalalalalaybdababawalalalalalbhal`zat`c`abcal`zalalajal`dalae``alalalalalal`y`galalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalala``yalalalalalalalalalalalalalalalalalalalalalalal`g`q`vaxazaaalalal`aaladal`m`aal``an`g`gaeal`falalalalalalal`halalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalbe`yalalalalalalalalalalalalalalalalalalalalalalalalauaeazazalalalal`aaqalaaalalaial`dalahataxalalalalalalalalabalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalal`y`yalalalalalalalalalalalalalalalalalalalalalalal`rasbe`malalalal`dazaraval`jalal`zbaal`dalalalalalalalalalanagalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalal`a`wbaalalalalalalalalalalalalalalalalalalalalalalauau`qazbhbialalaualbdalal`ralajalaialabalalalalalalalalalalanabalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalaxbcaxalalalalalalalalalalalalalalalalalalalalalakak`kbhaaalal`dan`oalal`halalbcavaybfbfalalalalalalalalalalalanakalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalay`uaralalalalalalalalalalalalalalalalalalalalacasbdb``dalal`fal`oal`a`jalaial`nalaj`aadbh`malalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalal`wb`alalalalalalalalalalalalalalalalalalalawbeau```wbbalaual`ualal`nalalacalbealafalalal`dakalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalbdbaalalalalalalalalalalalalalalal`gbc`galbaaubf`bazay`g`ibial`gadalaialaial`ladalalalalalau`aalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`y`walalalalalalalalalalalalatayalayauau`bau`s`qakazal`salal`talal``al`valauapalalalalalalaualalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalapbbb`alalalalalalalalalal`waladauauaubebiauakahaxalbdalal`w`salaialbhalbgahalalalalalalalal`palalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalavbcawalalalalalalal`safabauauaa`yalalalauauawalbealatalamalalabalakalauaealalalalalalalalalafalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalb`bb`calalalalalb`axauau`raa`calalalalaibial`walaparab`ealafal`w`i`gauaealalalalalalalalal`i`ualalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`wbbalalal`e`ibcau```d`s`a`aalal`ua`alalbibial`ual`ralalahalaualau`ualalalalalalalalalalalakalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`zaeal`ial`tau`vah`lalalalalavayalalalalalayal`jalal`hal`eaaalauatalalalalalalalalalalalar`balalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbe`walauau`b`fal`calalalalalalalalalalalalalajalalahalaual`fbbb`alalalalalalalalalalalalaealalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`may`xaubh`s`zalal`ialalalalalalalalalalalaualal`halalaialauaoal`aalalalalalalalalalalalana`alalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbabiau`caqajaaawaladalalalalalalalalalalal`zabalalahal`talarag`yalbhalalalalalalalalalalalalakalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaxalauauasalaj`wayap`ialalalalalalalalalalalaualalaealalaualaq`ya`albealalalalalalalalalalalaladalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`ybdau`f`v`yaw`a`i`y`aalalalalalalalalalalbe`salalafalaebialau`zalalaaalalalalalalalalalalalal`o`qalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`ialau`r`raj`hawbdalbgalalalalalalalalalalalaualalaaalal`valafah`ialbib`alalalalalalalalalalalalal`balalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalb`agauauahbb`jalbc`ualalalalalalalalalalaladaralal`nalbe`salaualalalbhalalalalalalalalalalalalalal`nalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalbialalalalalalalalalalalalalal`ialauauauazbbabalar`u`walalalalalalalalalalaoalalacbialaual`g`l`calalbfalalalalalalalalalalalalalalafalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalax``auaoa`aeazbd`g`sapbdayalalalalalalalal`palalalafalayadal`taxanalarar`malalalalalalalalalalalalalafalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalbibialalalalalalalalalalalalalal`cauauaiao`nb``g`zalal`i`y`calalalalalalav`jalalbdanalaualalauae`aalalal`zalalalalalalalalalalalalal`falalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`g`qauau`laj`uafat``alalalbda`alalalalalalasalalalajalal`lalbcau`salalalalbcalalalalalalalalalalalalalafalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalbibialalalalalalalalalalalalalb``jauao`j`pb`apax`ialalalalbdbfalalalalbaadalalbdaval`lalalauaxalalalalbealalalalalalalalalalalalalal`falalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbd`uauau`fagbgbi```ealalalalalbda`alalalaualalalajalalaualalaoacalalalalbialalalalalalalalalalalalalalafalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalbialalalalalalalalalalalalalal`gauau`h`dbdawbfaxalalalalalal`z`yal`s`zalalb``kal`p`ialai`tbialalalalalalalalalalalalalalalalalalal`jalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalapauaubgaa`a`ualalalalalalal`abcaraualalal`ralalaualal`v`kalalalalalalalalalalalalalalalalalalalal`ralalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`eaoau`z`d`m`qalalalalalalalalb`baa`alal`w`qal`zbealar`vbcalalalalalalalalalalalalalalalalalalalalafalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalatbgau`zabbiaralalalalalalalalal`s`walalasalalaualalah`w`aalalalalalalalalalalalalalalalalalalalal`falalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalavauadaoalazalalalalalalalalalal`zbbat`yal`c`jalalauayalalalalalalalalalalalalalalalalalalalalal`balalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`s`uau`sawalalalalavalalalalalalalbcaialalaualalabab`galalalalalalalalavalalalalalalalalalalalalacalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalayaualbaalalalalaualalalalalalalbibc`malaualal`t`qalalalalalalalalalaualalalalalalalalalalal`o`kalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaraqaealalalalalaualalalalalalalal`e`s`n`oal`oahbialalalalalalalalalau`ealalalalalalalalalalakalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`k`nakalalalalazaualalalalalalalalal`wbcalalaq`dalalalalalalalalalalau`balalalalalalalalalalaealalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaq`falalalalalauawalalalalalalalalalabbaalauaralalalalalalalalalalauaxalalalalalalalalalbhbialalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`p`ualalalalalauaualalalalalalalalalalacabajanalalalalalalalalala`aualalalalalalalalalaladalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalafalalalalalal`qaualalalalalalalalalalalab`yalalalalalalalalalalauasalalalalalalalalal`ca`alalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalagalalalalalalalau`aalalalalalalalalalav`b`o`walalalalalalalal`caualalalalalalalalalalahalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalala`alalalalalalalau`malalalalalalalalalaoalbi`z`salalalalalalalazaualalalalalalalalal`i`oalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalabalalalalalalalaualalalalalalalalalalajal`obf`o`kalalalalalalb`aualalalalalalalalal`jalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`s`galalalalalalalaualalalalalalalalalbhavaladalbbay`aalalalalalalaualalalalalalalalbdaralalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaealalalalalalalalalalalalalalalalalalaualaladalal`t`ualalalalalal`zalalalalalalal`ebaalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`ualalalalalalalalalalalalalalalalal`eadalafanalbbal`uaaalalalalalalalalalaralalalaealalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaialalahalal`bal`gbfbgalalalalalalalat`palal`dalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`ralaladalalacal`balbcaxalalalalalal``alalbi`malalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`ealalalalalalalalalac`kal`lalal`savalafal`ybbalalalalalaealalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`halalalalalalalalal`xalal`ralalbhalalaealbfa`alalalalacalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbcaralalalalalalalal`gbgal`qbealalafalbdalalbbaealalalb``ualalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`palalalalalalalalalaoalalaualal`iaxal``alalalalalalal`ralalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`yalb`alalalalalalalalaoalalaualaladalal``alalalalalal`k`zalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`zalaaalalalalalalaladaralbd`qalaladalaw`kalalalalalal`talalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`eavalalalalalalalaualalaualalavbbalaealalalalalalal`nalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaualalalalalalal`walalalalalalal`g`balalacalalbhalalbhalalalalalalbhalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalazaualalalalalalalbealalalalalalal`valalazayalalacalanb`alalalalalal`valalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalauauapalalalalalal`walalalalalalalasalalafalal`a`ualabalalalalalalal`ralalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaeauauabalalalalalavayalalalalalal`f`galalafalal`dalal`dalalalalalalal``alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalauauaoaualalalalalalalalalalalalalaualala`bialal`falal`balalalalala``o`yalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalaqauau``aualalalalalalalalalalalal`g`balalafalalal`walbbapalalalalatajbhbaalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalal`aau`nauajai``alalalalalalalalalalalaoalalal`balal``alal`falalalalalalad`nbbalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalauau`x`t`ladaualalalalalalalalalalalaoalal`zalalalafalalbhalalalarayba`t`tbfalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalb`auauaqbham```zaaalalalalalalalalalab`galal`falalalabalawaxalalalalararabau`nalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalauauaqaubhau`ybhaibialalalalalalalal`ralal`aaaalalbealal``alalalalalal`mbdau`jbcalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalal`sauam`vaoa`aea``tabbbalalalalalalalal`balalaealalalaealalbhalalalalal`cbgamaiau`tat`zaaacav`aalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalauauau`xas`f`jaoae`saa`oalalalalalal`lalalalafalalalaaalalbealalalal`iatbbbf`hamao`halav`qat`nbhac`o`y`salalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalauauauaf`p`dadagbh`l`e`falalalalalal`lalalavbcalalbcanalaaalalalalalal`m`u`b```lau`sazal`ualalazbhalapalab`zac`salalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalauaqau`p`xajbgas`o`ualbe`ralalalalaxb`alalafalalalahalaladalalalalalalalazb`aeaoajauagadbdbaahan`c`q`wapalalalbc`dbe`oalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalal`o`salauaqau`p`yafbg```bawacajbh`nalalal`jalalal`nalalal`dalal``alalalalalal`sav`ob`ai`lau`v`vak`ja`awbeat`e`e`s`u`a`a`garbeab`u`yalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalarbc`s`baeb`a`alauauau`pauau`dbfaa`u`y`m`ibaaualalaealal`q`oalalb`aralaz`ealalalalalalal`o`zb`be`d`fasauauafbcalalayafavbbalb``salalalal`e`wabbh`ealalalalalalalalal",
-"alalalalalalalalalalalalalalal`i`z`nbh`g`k`oavapalalajauau`f`dakacavay`sbaa``dapbg`daqalalal`nalalal`dalal`balalalalalalalalalbbbfagbcas`fau`xbha``z`ualalalavalalalat`eatawawalalal`kaabbalalalalalalal",
-"alalalalalalalalalalalalalbb`y`gal`a`mavaaaxalbeaaay`qauam`jaoaa`jagakaqbb`g`iacalalauaga`al`balalal`balal`balalalalalalalalal`z`sbhbh`j``akauae```aalalalaraz`q`oat`eal`g`aalaralalatalav`tbgalalalalal",
-"alalalalalalalalalalavai`u`i``ayalalalarav`ka``o`yayalau`xasam`zag`mazabap`mbaal`may`ybi`kau`balal`gawal`c`salalalalalalalalat`ibaaz```bakakau`uaxalb`abbb`oazayalarb``sbibiazazal`kaval`gav`eakatalalal",
-"alalalalalalalalaz`fayalbf`ealbebe`salal`oaxbi`eaxaab`bgau`jam`dbc`sae`wad`m`gayal`talalal`jalaiabbfalalbfalalalalalalalalanayar`o`yaa`lahaeauaf`q`t`savax`malalalalalalalalanaxapat`ebbbial`calat`balal",
-"alalalalalalaladatalalalalb`arapalbdae`oalalalatalalanbiauau`l`vahag`y`iaw`zalalawajal`gawadalalalauaua``dalalalalalalalal`q`gaw``aaazajaiakau`ubealalalalal`g`calalar`ealal`cb`an`ual`g`say`aalay`e`wal",
-"alalalalalal``analalalal`c`k`m`m`k`g`malalalalalalalalalazauasau`hbdb`a`bdbdalawbca`baal``alalalarayal`aauaj`bauauamajas`t`waw`cab`ubf`nbhamaualau`e`eatazazarar`m`u`ealalalalal`may`qalalav`u`iawaladal",
-"alalalalbibgalalalalal`a`oalanalalavax`galalal`iawayalalalauauao`zaa`bbhalbhadalasal`gal`palalaladalal`aalalalalalalalalalalalan`marabbgaiauaiarazalalalal`gatalalaxavalalalal`s`ialalan`qalalaz`cal`dal",
-"alalalal`dalanazalaralalanalalayavaval`sa`adbf`ialalalalal`sauam`nbb`gacbfacal`wajalalal``alalal`malalalalalalalalalalalalalbaav`k`wauacasbf`iajalalalalapal`a`zavalal`abc`oaralalal`qavalat`obi`ub`atal",
-"alalalbhalalalar`calal`gatavaxaxax`maralalalalalatazatalalalauau`n``bc`sbc`qa`alal`calajalalalalalalalalalalalalalalalalalalaybfahacagbcaiac``al`mbbbbapalalanalal`ebcavalalalb``w`mal`i`walaw`c`cbbalal",
-"alalal`fal`ialal`mavayaralawatalalalalal`c`ialalalalalalalalalauauahafak`q`q`aal`ualalaqalalalalalalalalalalalalalalalalalalal`obcaxbebh`nbc`qalalalalalal`gb`axalalalalalba`malalalaralal`galar`walalal",
-"alalalaealal`kavalalar`k`aanapalalapalalarazaw`capal`aalalalalalauamaubdaf```qbibgal`ebealalalalalalalalalalalalalalal`u`o`c`oab`b`f`zac`u``alalaz`sbb`qalalalalbc`wbaanalbialalal`a`o`m`ealba`oalalalal",
-"alalalbbaaap`yaeaja``ial`oalaranalalal`m`yawan`m`u`kalapalaw`ualalauao`rbcaxaual`u`k`jalalalalalalalalalalalalalal`oaxalalaz`wae`fafagag`nalalalalalalalal`c`ealalalalalalalalaw`obialb`biaeapalalalalal",
-"alalalalalagalalal`a`o`q`ialalal`abc`zalalba`mal`ealazalbdbiaxaralal`vauahabak`kaz`zalalalalalalalalalalalalalalalalalb`azawalavaj``az`palalalalalal`e`sapapalalalal`ealaw`s`y`walay`o`ubcalalalalalalal",
-"alalalalalalbbbdalalalalalalal`uawalalalalawayaxaxb`alazavaz`g`kavalal`kauag`paz`ya`alalalalalalalalalalalalalalalalalaw`mb`ab`zala``balalalalalalalalalalalal`o`uaz`galalananal`q`w`ualalalalalalalalal",
-"alalalalalalalanaa`ualalalav`zalalat`g`oaz`e`o`eav`k`c`oax`eazaral`ial`m`m`tau`bahap`yapalalalalalalalalalalalalalalalalalalalalaeavalalalavaxav`qawalalal`g`qapalalalalalalava``ualalalalalalalalalalal",
-"alalalalalalalalalbiad`nayalalalalalb`awaz`eat`qalay`i`galaxalal`saybfanalalbdauac`s`q`valalalalalalalal`iat`eay`earbfbg`pau`vaaal`oawal`karalalalalalalalatalalalalalbcbha`axalalalalalalalalalalalalal",
-"alalalalalalalalalalalal`iaabfbcalalalalalalalalacazbiav`u`m`g`ua``kalalalalalal`faubeac`calalalalalal`uaf`baf`hahaca``ialalalbi`ianalalalalalalalalalalalalataibb`u`wanalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalbiaca`aa`yalalalalalalanalalbcbhavalalalalalalalalalap`b`oarb`alalalalalalalalalalalal`calalalalbialalalalalalalalalalb`bga`acavalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalat`wabbhbgb``qaabebfalalalalalalalalalalalalalalapbc`l`pbialalalalalalalalalalalalalalalalalalalalal`s``a`bf`zalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalala`ahadbh`db`bcbiatalalalal`ubcaf`wacbe`fae`uanalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`g`gabbgababav`ialalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaxalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalafaealalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal`oal`z`l`wbhafalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalauagbeaqal`mb`alalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalaf`mbialalaaalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbaalalalalalalalalalalalalalalalal",
-"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalbialalalalalalalalalalalalalalalal"
-};
--- /dev/null
+# Documentation/tex/Makefile
+
+depth=../..
+
+TEX_FILES = $(wildcard *.tex)
+DOC_FILES = $(wildcard *.doc)
+DVI_FILES = $(addprefix $(outdir)/,$(DOC_FILES:.doc=.dvi) $(TELY_FILES:.tely=.dvi))
+
+OUTTEX_FILES = $(addprefix $(outdir)/, $(TEX_FILES))
+OUTDOC_FILES = $(addprefix $(outdir)/, $(DOC_FILES))
+
+EXTRA_DIST_FILES= $(DOC_FILES) $(TEX_FILES) $(wildcard *.sty)
+HTML_FILES = $(addprefix $(outdir)/, $(TEXI_FILES:.texi=.html) $(TELY_FILES:.tely=.html))
+PS_FILES = $(DVI_FILES:.dvi=.ps)
+
+STEPMAKE_TEMPLATES=tex documentation texinfo
+LOCALSTEPMAKE_TEMPLATES=lilypond mudela
+
+export BIBINPUTS:=$(shell pwd)//$(PATHSEP)$(BIBINPUTS)
+include $(depth)/make/stepmake.make
+
+dvi: $(DVI_FILES)
+
+ps: $(PS_FILES)
+
+# urg
+default:
+
+
+localclean:
+ rm -f fonts.aux fonts.log feta*.tfm feta*.*pk
+
+local-WWW: $(HTML_FILES)
+ $(PYTHON) $(step-bindir)/ls-latex.py --title 'Hacker documentation' \
+ $(DOC_FILES) $(TEXI_FILES) $(TELY_FILES) \
+ | sed "s!$(outdir)/!!g" > $(outdir)/index.html
--- /dev/null
+% Creator: mf-to-table.py version 0.7
+% Automatically generated on
+% Do not edit
+% input from out/feta20.log
+% name
+% rests
+\fetdef\wholerest{0}
+\fetdef\halfrest{1}
+\fetdef\outsidewholerest{2}
+\fetdef\outsidehalfrest{3}
+\fetdef\breverest{4}
+\fetdef\longarest{5}
+\fetdef\multirest{6}
+\fetdef\quartrest{7}
+\fetdef\eighthrest{8}
+\fetdef\sixteenthrest{9}
+\fetdef\thirtysecondrest{10}
+\fetdef\sixtyfourthrest{11}
+\fetdef\hundredtwentyeighthrest{12}
+
+% accidentals
+\fetdef\sharp{13}
+\fetdef\natural{14}
+\fetdef\flat{15}
+\fetdef\flatflat{16}
+\fetdef\sharpsharp{17}
+\fetdef\rightparen{18}
+\fetdef\leftparen{19}
+
+% dots
+\fetdef\dot{20}
+\fetdef\repeatcolon{21}
+
+% balls
+\fetdef\brevisball{22}
+\fetdef\brevisledger{23}
+\fetdef\longaball{24}
+\fetdef\longaledger{25}
+\fetdef\wholeball{26}
+\fetdef\wholeledger{27}
+\fetdef\halfball{28}
+\fetdef\halfledger{29}
+\fetdef\quartball{30}
+\fetdef\quartledger{31}
+
+% scripts
+\fetdef\ufermata{32}
+\fetdef\dfermata{33}
+\fetdef\thumb{34}
+\fetdef\sforzatoaccent{35}
+\fetdef\staccato{36}
+\fetdef\ustaccatissimo{37}
+\fetdef\dstaccatissimo{38}
+\fetdef\tenuto{39}
+\fetdef\umarcato{40}
+\fetdef\dmarcato{41}
+\fetdef\ouvert{42}
+\fetdef\plusstop{43}
+\fetdef\upbow{44}
+\fetdef\downbow{45}
+\fetdef\reverseturn{46}
+\fetdef\turn{47}
+\fetdef\trill{48}
+\fetdef\upedalheel{49}
+\fetdef\dpedalheel{50}
+\fetdef\upedaltoe{51}
+\fetdef\dpedaltoe{52}
+\fetdef\flageolet{53}
+\fetdef\trilelement{54}
+\fetdef\prall{55}
+\fetdef\mordent{56}
+\fetdef\prallprall{57}
+\fetdef\prallmordent{58}
+\fetdef\upprall{59}
+\fetdef\downprall{60}
+\fetdef\accDiscant{61}
+\fetdef\accDiscantF{62}
+\fetdef\accDiscantEh{63}
+\fetdef\accDiscantE{64}
+\fetdef\accDiscantFE{65}
+\fetdef\accDiscantFEh{66}
+\fetdef\accDiscantEE{67}
+\fetdef\accDiscantFEE{68}
+\fetdef\accDiscantEEE{69}
+\fetdef\accDiscantFEEE{70}
+\fetdef\accDiscantS{71}
+\fetdef\accDiscantFS{72}
+\fetdef\accDiscantES{73}
+\fetdef\accDiscantEhS{74}
+\fetdef\accDiscantFES{75}
+\fetdef\accDiscantFEhS{76}
+\fetdef\accDiscantEES{77}
+\fetdef\accDiscantFEES{78}
+\fetdef\accDiscantEEES{79}
+\fetdef\accDiscantFEEES{80}
+\fetdef\accDiscantSS{81}
+\fetdef\accDiscantESS{82}
+\fetdef\accDiscantEESS{83}
+\fetdef\accDiscantEEESS{84}
+\fetdef\accFreebass{85}
+\fetdef\accFreebassF{86}
+\fetdef\accFreebassE{87}
+\fetdef\accFreebassFE{88}
+\fetdef\accStdbass{89}
+\fetdef\accStdbassM{90}
+\fetdef\accStdbassBp{91}
+\fetdef\accStdbassT{92}
+\fetdef\accStdbassTp{93}
+\fetdef\accBayanbass{94}
+\fetdef\accBayanbassT{95}
+\fetdef\accBayanbassE{96}
+\fetdef\accBayanbassTE{97}
+\fetdef\accBayanbassEE{98}
+\fetdef\accBayanbassTEE{99}
+\fetdef\accSB{100}
+\fetdef\accBB{101}
+\fetdef\accOldEE{102}
+\fetdef\accOldEES{103}
+
+% flags
+\fetdef\eighthflag{104}
+\fetdef\sixteenthflag{105}
+\fetdef\thirtysecondflag{106}
+\fetdef\sixtyfourthflag{107}
+\fetdef\deighthflag{108}
+\fetdef\dsixteenthflag{109}
+\fetdef\dthirtysecondflag{110}
+\fetdef\dsixtyfourthflag{111}
+
+% clefs
+\fetdef\altoclef{112}
+\fetdef\caltoclef{113}
+\fetdef\bassclef{114}
+\fetdef\cbassclef{115}
+\fetdef\trebleclef{116}
+\fetdef\ctrebleclef{117}
+
+% timesig
+\fetdef\fourfourmeter{118}
+\fetdef\allabreve{119}
+\fetdef\oldfourfourmeter{120}
+\fetdef\oldallabreve{121}
+\fetdef\oldthreetwometer{122}
+\fetdef\oldsixfourmeter{123}
+\fetdef\oldninefourmeter{124}
+
--- /dev/null
+
+ % -*-LaTeX-*-
+
+\documentclass{article}
+\def\kdots{,\ldots,}
+\title{Not the Font-En-Tja font}
+\author{HWN \& JCN}
+\def\preMudelaExample{}
+\def\postMudelaExample{}
+\begin{document}
+\maketitle
+
+
+\section{Introduction}
+
+This document are some design notes of the Feta font, and other
+symbols related to LilyPond. Feta (not an abbreviation of
+Font-En-Tja) is a font of music symbols. All MetaFont sources are
+original. The symbols are modelled after various editions of music,
+notably \begin{itemize} \item B\"arenreiter \item Hofmeister \item
+Breitkopf \item Durand \& C'ie \end{itemize}
+
+The best references on Music engraving are Wanske\cite{wanske} and
+Ross\cite{ross} some of their insights were used. Although it is a
+matter of taste, I'd say that B\"arenreiter has the finest typography
+of all.
+
+
+\section{Bezier curves for slurs}
+
+Objective: slurs in music are curved objects designating that notes
+should fluently bound. They are drawn as smooth curves, with their
+center thicker and the endings tapered.
+
+There are some variants: the simplest slur shape only has the width as
+parameter. Then we give some suggestions for tuning the shapes. The
+simple slur algorithm is used for drawing ties as well.
+
+
+
+\subsection{Simple slurs}
+
+Long slurs are flat, whereas short slurs look like small circle arcs.
+Details are given in Wanske\cite{ross} and Ross\cite{wanske}. The
+shape of a slur can be given as a Bezier curve with four control
+points:
+
+\begin{eqnarray*}
+ B(t) &=& (1-t)^3c_1 +3(1-t)^2tc_2 + 3(1-t)t^2c_3 + t^3c_4.
+\end{eqnarray*}
+
+We will assume that the slur connects two notes of the same
+pitch. Different slurs can be created by rotating the derived shape.
+We will also assume that the slur has a vertical axis of symmetry
+through its center. The left point will be the origin. So we have
+the following equations for the control points $c_1\kdots c_4$.
+
+\begin{eqnarray*}
+c_1&=& (0,0)\\
+c_2&=& (i, h)\\
+c_3&=& (b-i, h)\\
+c_4&=& (b, 0)
+\end{eqnarray*}
+
+The quantity $b$ is given, it is the width of the slur. The
+conditions on the shape of the slur for small and large $b$ transform
+to
+\begin{eqnarray*}
+ h \to h_{\infty} , &&\quad b \to \infty\\
+ h \approx r_{0} b, &&\quad b \to 0.
+\end{eqnarray*}
+To tackle this, we will assume that $h = F(b)$, for some kind of
+$F(\cdot)$. One function that satisfies the above conditions is
+$$
+F(b) = h_{\infty} \frac{2}{\pi} \arctan \left( \frac{\pi r_0}{2
+h_{\infty}} b \right).
+$$
+
+For satisfying results we choose $h_{\infty} = 2\cdot \texttt{interline}$
+and $r_0 = \frac 13$.
+
+\subsection{Height correction}
+
+Aside from being a smooth curve, slurs should avoid crossing
+enclosed notes and their stems.
+
+An easy way to achieve this is to extend the slur's height,
+so that the slur will curve just above any disturbing notes.
+
+The parameter $i$ determines the flatness of the curve. Satisfying
+results have been obtained with $i = h$.
+
+The formula can be generalised to allow for corrections in the shape,
+\begin{eqnarray*}
+c_1&=& (0,0)\\
+c_2&=& (i', h')\\
+c_3&=& (b-i', h')\\
+c_4&=& (b, 0)
+\end{eqnarray*}
+Where
+$$
+i' = h(b) (1 + i_{corr}), \quad h' = h(b) (1 + h_{corr}).
+$$
+
+The default values for these corrections are $0$. A $h_{corr}$ that is
+negative, makes the curve flatter in the center. A $h_{corr}$ that is
+positive make the curve higher.
+
+At every encompassed note's x position the difference $\delta _y$
+between the slur's height and the note is calculated. The greatest
+$\delta _y$ is used to calculate $h_{corr}$ is by lineair extrapolation.
+
+However, this simple method produces satisfactory results only for
+small and symmetric disturbances.
+
+
+\subsection{Tangent method correction}
+
+A somewhat more elaborate\footnote{While staying in the realm
+of empiric computer science} way of having a slur avoid
+disturbing notes is by first defining the slur's ideal shape
+and then using the height correction. The ideal shape of a
+slur can be guessed by calculating the tangents of the disturbing
+notes:
+% a picture wouldn't hurt...
+\begin{eqnarray*}
+ y_{disturb,l} &=& \rm{rc}_l x\\
+ y_{disturb,r} &=& \rm{rc}_r + c_{3,x},
+\end{eqnarray*}
+where
+\begin{eqnarray*}
+ \rm{rc}_l &=& \frac{y_{disturb,l} - y_{encompass,1}}
+ {x_{disturb,l} - x_{encompass,1}}\dot x\\
+ \rm{rc}_r &=& \frac{y_{encompass,n} - y_{disturb,r}}
+ {x_{encompass,n} - x_{disturb,r}} \dot x + c_{3,x}.
+\end{eqnarray*}
+
+We assume that having the control points $c_2$ and $c_3$ located
+on tangent$_1$ and tangent$_2$ resp.
+% t: tangent
+\begin{eqnarray*}
+ y_{tangent,l} &=& \alpha \rm{rc}_l x\\
+ y_{tangent,r} &=& \alpha \rm{rc}_r + c_{3,x}.
+\end{eqnarray*}
+
+Beautiful slurs have rather strong curvature at the extreme
+control points. That's why we'll have $\alpha > 1$.
+Satisfactory resulsts have been obtained with
+$$
+ \alpha \approx 2.4.
+$$
+
+The positions of control points $c_2$ and $c_3$ are obtained
+by solving with the height-line
+\begin{eqnarray*}
+ y_h &=& \rm{rc}_h + c_h.
+\end{eqnarray*}
+
+The top-line runs through the points disturb$_{left}$ and
+disturb$_{right}$. In the case that
+$$
+z_{disturb,l} = z_{disturb,r},
+$$
+we'll have
+$$
+ \angle(y_{tangent,l},y_h) = \angle(y_{tangent,r},y_h).
+$$
+
+
+
+\section{Sizes}
+
+Traditional engraving uses a set of 9 standardised sizes for Staffs
+(running from 0 to 8).
+
+We have tried to measure these (helped by a magnifying glass), and
+found the staffsizes in table~\ref{fonts:staff-size}. One should note that
+these are estimates, so I think there could be a measuring error of ~
+.5 pt. Moreover [Ross] states that not all engravers use exactly
+those sizes.
+
+\begin{table}[h]
+ \begin{center}
+ \begin{tabular}{lll}
+Staffsize &Numbers &Name\\
+\hline\\
+26.2pt &No. 0\\
+22.6pt &No. 1 &Giant/English\\
+21.3pt &No. 2 &Giant/English\\
+19.9pt &No. 3 &Regular, Ordinary, Common\\
+19.1pt &No. 4 &Peter\\
+17.1pt &No. 5 &Large middle\\
+15.9pt &No. 6 &Small middle\\
+13.7pt &No. 7 &Cadenza\\
+11.1pt &No. 8 &Pearl\\
+ \end{tabular}
+ \caption{Foo}
+ \label{fonts:staff-size}
+ \end{center}
+\end{table}
+
+
+
+
+\section{Beams}
+
+\subsection{Slope}
+
+Traditionally, beam slopes are computed by following a large and hairy
+set of rules. Some of these are talked-about in Wanske, a more
+recipy-like description can be found in Ross.
+
+There are some problems when trying to follow these rules:
+\begin{itemize}
+
+\item the set is not complete
+
+\item they are not formulated as a general rule with exceptions, but
+rather as a huge case of individual rules\cite{ross}
+
+\item in some cases, the result is wrong or ugly (or both)
+
+\item they try to solve a couple of problems at a time (e.g. Ross
+handles ideal slope and slope-quantisation as a paired problem)
+\end{itemize}
+Reading Ross it is clear that the rules presented there are certainly
+not the ultimate idea of what beam(slope)s should look like, but
+rather a (very much) simplified hands-on recipy for a human engraver.
+
+There are good reasons not to follow those rules:
+
+\begin{itemize}
+\item One cannot expect a human engraver to solve least-squares
+problems for every beam
+
+\item A human engravers will allways trust themselves in judging the
+outcome of the applied recipy. If, in a complicated case, the result
+"doesn't look good", they will ignore the rules and draw their own
+beams, based on experience.
+
+\item The exact rules probably don't "really exist" but in the minds
+ of good engravers, in the form of experience
+\end{itemize}
+
+We'll propose to do a least-squares solve. This seems to be the best
+way to calculate the slope for a computerised engraver such as Lily.
+
+It would be nice to have some rules to catch and handle "ugly" cases,
+though. In general, the slope of the beam should mirror the pitches
+of the notes. If this can't be done because there simply is no
+uniform trend, it would probably be best to set the slope to zero.
+
+
+\subsection{Quantising}
+
+The beams should be prevented to conflict with the stafflines,
+especially at small slopes. Traditionally, poor printing techniques
+imposed rather strict rules for quantisation. In modern (post 1955)
+music printing we see that quality has improved substantially and
+obsoleted the technical justification for following some of these
+strict rules, notably the avoiding of so-called wedges.
+
+
+\subsection{Thickness and spacing}
+
+The spacing of double and triple beams (sixteenth and thirtysecond beams)
+is the same, quadruple and quintuple (thirtyfourth and hundredtwentyeighth
+beams) is wider.
+All beams are equally thick. Using the layout of triple beams and the
+beam-thickness $bt$ we can calculate the inter-beam spacing $ib$.
+
+Three beams span two interlines, including stafflines:
+\begin{eqnarray*}
+ 2 ib + bt &=& 2 il\\
+ ib &=& (2 il - bt) / 2
+\end{eqnarray*}
+
+We choose
+\begin{eqnarray*}
+ bt &=& 0.48(il - st)
+\end{eqnarray*}
+
+\subsubsection{Quadruple beams}
+
+If we have more than three beams they must open-up
+in order to not collide with staff lines. The only valid
+position that remains is for the upper beam to hang.
+
+\begin{eqnarray*}
+ 3 ib_{4+} + bt &=& 3 il\\
+ ib_{4+} &=& (3 il - bt) / 3
+\end{eqnarray*}
+
+
+\section{Layout of the source files}
+
+The main font (with the fixed size music glyphs) uses a the \TeX\
+logfile as a communication device. Use the specialised macros to
+create and export glyphs.
+
+\bibliographystyle{plain}
+\bibliography{engraving}
+
+
+
+\end{document}
+
+\begin{verbatim}
+Paul Terry <paul@musonix.demon.co.uk> writes:
+
+Ross states that the dies (the stamps to make the symbols) come in
+12 different sizes.
+
+>Can you tell me how big rastrals are?
+
+According to the Score manual:
+
+ Rastral Size Height in millimetres
+
+ 0 9 mm
+ 1 8 mm
+ 2 7.5 mm
+ 3 7 mm
+ 4 6.5 mm
+ 5 6 mm
+ 6 5.5 mm
+
+I must say, despite having been a music setter for many years, I had to
+look these up - none of the publishers I work for deal in Rastral sizes
+these days (they all use millimetres).
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@setfilename internals.info
+@settitle LilyPond internals
+
+@node Top, LilyPond internals, (dir), (dir)
+@top
+
+
+@menu
+* LilyPond internals::
+* Overview::
+* mudela::
+* Request_engraver::
+* Graphic elements::
+* Score elements::
+* Items::
+* Spanners::
+* Future work::
+* Coding standards::
+* Making patches::
+
+@end menu
+
+@node LilyPond internals, , Top, Top
+@menu
+* Overview:: Overview
+* mudela:: mudela
+* Request_engraver:: Request_engraver
+@end menu
+
+
+@chapter Getting involved
+
+Please help us make LilyPond a better program. You can help LilyPond in
+several ways. Not all tasks requiring programming or understanding the
+full source code. You can write to the mailing list
+(@email{gnu-music-discuss@@gnu.org} for more information)
+
+@unnumberedsubsec Users
+
+Mutopia needs your help. The mutopia project is a collection of public
+domain sheet music. You can help the project by entering music and
+submitting. Point your browser to the
+@uref{http://sca.uwaterloo.ca/Mutopia, Mutopia webpage}
+
+@unnumberedsubsec Font designers
+
+Our set of glyphs (the Feta font) is far from complete. If you know a
+little MetaFont you can contribute a glyph
+
+@unnumberedsubsec Writers
+
+The documentation of LilyPond and related utilities needs a lot of work.
+
+@unnumberedsubsec Translators
+
+LilyPond is completely ready for internationalized messages, but there
+are only three translations so far.
+
+@unnumberedsubsec Hackers
+
+
+There are lots of possibilities of improving the program itself. There are
+both small projects and big ones. Most of them are listed in the TODO
+file. A interesting and very big project is writing a GUI frontend to
+LilyPond.
+
+
+
+@chapter LilyPond internals
+
+
+This documents some aspects of the internals of GNU LilyPond. Some of
+this stuff comes from e-mail I wrote, some from e-mail others wrote,
+some are large comments taken away from the headers. This page may be
+a little incoherent. Unfortunately, it is also quite outdated. A
+more thorough and understandable document is in the works.
+
+You should use @code{doc++} to take a peek at the sources.
+
+@node Overview, mudela, Top, Top
+@section Overview
+
+GNU LilyPond is a "multi-pass" system. The different passes have been
+created so that they do not depend on each other. In a later stage
+some parts may be moved into libraries, or seperate programs, or they
+might be integrated in larger systems.
+
+@table @samp
+
+@item Parsing:
+
+No difficult algorithms. The .ly file is read, and converted to a list
+of @code{Scores}, which each contain @code{Music} and paper/midi-definitions.
+
+@item Interpreting music
+
+The music is walked through in time-order. The iterators which do the
+walking report Music to Translators which use this information to
+create elements, either MIDI or "visual" elements. The translators
+form a hierarchy; the ones for paper output are Engravers, for MIDI
+Performers.
+
+The translators swallow Music (mostly atomic gobs called Requests),
+create elements, broadcast them to other translators on higher or same
+level in the hierarchy:
+
+The stem of a voice A is broadcast to the staff which contains A, but
+not to the stems, beams and noteheads of a different voice (say B) or
+a different staff. The stem and noteheads of A are coupled, because
+the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
+these.
+
+The engraver which agrees to handle a request decides whether to to
+honor the request, ignore it, or merge it with other requests. Merging
+of requests is preferably done with other requests done by members of
+the same voicegroups (beams, brackets, stems). In this way you can put
+the voices of 2 instruments in a conductor's score so they make chords
+(the Beam requests of both instruments will be merged).
+
+@item Prebreaking
+
+Breakable stuff (eg. clefs and bars) are copied into pre and
+postbreaks.
+
+@item Preprocessing
+
+Some dependencies are resolved, such as the direction of stems, beams,
+and "horizontal" placement issues (the order of clefs, keys etc,
+placement of chords in multi-voice music),
+
+@item Break calculation:
+
+The lines and horizontal positions of the columns are determined.
+
+@item Breaking
+
+Through some magical interactions with Line_of_score and Super_elem
+(check out the source) the "lines" are produced.
+
+All other spanners can figure across which lines they are spread. If
+applicable, they break themselves into pieces. After this, each piece
+(or, if there are no pieces, the original spanner itself) throws out
+any dependencies which are in the wrong line.
+
+@item Postprocesing:
+
+Some items and all spanners need computation after the Paper_column
+positions are determined. Examples: slurs, vertical positions of
+staffs.
+
+@item Output paper
+
+@end table
+
+@node mudela, Request_engraver, Overview, Top
+@section mudela
+
+Most information is stored in the form of a request. In music
+typesetting, the user might want to cram a lot more symbols on the
+paper than actually fits. To reflect this idea (the user asks more
+than we can do), the container for this data is called Request.
+
+In a lot of other formats this would be called an 'Event'
+
+@table @samp
+@item @code{Barcheck_req}
+ Checks during music processing if start of this voice element
+ coincides with the start of a measure. Handy to check if you left out
+ some voice elts.
+@item @code{Note_req}
+ LilyPond has to decide if the ball should be hanging left or
+ right. This influences the horizontal dimensions of a column, and this
+ is why request processing should be done before horizontal spacing.
+ Other voices' frivolities may cause the need for accidentals, so this
+ is also for the to decide. The engraver can decide on positioning based on
+ ottava commands and the appropriate clef.
+@item @code{Rest_req}
+ Typeset a rest.
+@item @code{Span_req}
+ This type of request typically results in the creation of a @code{Spanner}
+@item @code{Beam_req}
+ Start/stop a beam.
+ Engraver has to combine this request with the stem_request, since the
+ number of flags that a stem wants to carry will determine the
+ number of beams.
+@item @code{Dynamic}
+ Each dynamic is bound to one note (a crescendo spanning multiple
+ notes is thought to be made of two "dynamics": a start and a stop).
+ Dynamic changes can occur in a smaller time than the length of its
+ note, therefore fore each @code{Dynamic} request carries a time, measured
+ from the start of its note.
+@end table
+
+@node Request_engraver, , mudela, Top
+@section Request_engraver
+
+In the previous section the idea of Request has been explained, but
+this only solves one half of the problem. The other half is deciding
+which requests should be honored, which should merged with other
+requests, and which should be ignored. Consider this input
+
+@example
+
+ \type Staff < % chord
+ @{ \meter 2/4; [c8 c8] @}
+ @{\meter 2/4; [e8 e8] @}
+ >
+
+@end example
+
+Both the cs and es are part of a staff (they are in the same
+Voice_group), so they should share meters, but the two [ ] pairs
+should be merged.
+
+The judge in this "allocation" problem a set of brokers: the requests
+are transmitted to so-called engravers which respond if they want to
+accept a request eg, the @code{Notehead_engraver} will accept
+@code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator
+cannot find a engraver that wants the request, it is junked (with a
+warning message).
+
+After all requests have been either assigned, or junked, the Engraver
+will process the requests (which usually means creating an @code{Item}
+or @code{Spanner}). If a @code{Request_engraver} creates something, it
+tells the enclosing context. If all items/spanners have been created,
+then each Engraver is notified of any created Score_element, via a
+broadcasting system.
+
+@unnumberedsubsec example:
+
+@example
+
+ c4
+
+@end example
+
+produces:
+
+@example
+
+ Note_request (duration 1/4)
+ Stem_request (duration 1/4)
+
+@end example
+
+Note_request will be taken by a @code{Notehead_engraver}, stem_request
+will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver}
+creates a @code{Notehead}, @code{Stem_beam_engraver} creates a
+@code{Stem}. Both announce this to the Staff_engraver. Staff_engraver
+will tell @code{Stem_beam_engraver} about the @code{Notehead}, which
+will add the @code{Notehead} to the @code{Stem} it just created.
+
+To decide on merging, several engravers have been grouped. Please
+check @file{init/engraver.ly}.
+
+
+
+@node Graphic elements, , , Top
+@section Graphic elements
+
+
+Music notation is composed of a sets of interrelated glyphs. In
+Lilypond every glyph usually is represented by one object, a so-called
+Graphic Object. The primary relations between graphic objects involve
+positions:
+
+@itemize
+@item consecutive notes are printed left to right, grouped in a staff
+@item simultaneous notes are horizontally aligned (internally grouped in
+a paper column).
+@item the staccato mark is horizontally centered on the note it applies
+to.
+@end itemize
+
+The abstract encoding of such relations is done with the concept
+@dfn{reference point}. The reference point (in X direction) of the
+staccato mark is the note it applies to. The (X) position of the
+staccato mark is stored relative to the position of the note head. This
+means that the staccato will always maintain a fixed offset wrt to the
+note head, whereever the head is moved to.
+
+In the same vein, all notes on a staff have their Y positions stored
+relative to an abstract object called Axis_group_spanner. If the
+Axis_group_spanner of one staff is moved, the absolute Y positions of
+all objects in that spanner change along, in effect causing the staff
+and all its contents to move as a whole.
+
+Each graphic object stores a pointer and an relative offset for each
+direction: one for the X-axis, one for the Y-axis. For example, the X
+parent of a Note_head usually is a Note_column. The X parent of a
+Note_column usually is either a Collision or a Paper_column. The X
+parent of a Collision usually is a Paper_column. If the Collision
+moves, all Note_heads that have that Collision as parent also move, but
+the absolute position of the Paper_column does not change.
+
+To build a graphical score with Graphic_elements, conceptually, one
+needs to have one Root object (in Lilypond: Line_of_score), and
+recursively attach objects to the Root. However, due to the nature
+of the context selection mechanisms, it turns out to be more
+advantageous to construct the tree the other way around: first small
+trees (note heads, barlines etc.) are created, and these are
+subsequently composed into larger trees, which are finally hung on a
+Paper_column (in X direction) or Line_of_score (in Y direction).
+
+The structure of the X,Y parent relations are determined by the
+engravers and notation contexts:
+
+The most important X-axis parent relation depends on the timing: notes
+that come earlier are attached to Paper_column that will be positioned
+more to the left.
+
+The most important Y-axis relation depends on containment of contexts:
+notes (created in a Thread or Voice context) are put in the staff where
+the originating context lives in.
+
+Graphical_axis_groups are special graphic objects, that are designed to
+function as a parent. The size of a Graphical_axis_groups group is the
+union of its children.
+
+@node Score elements, , , Top
+
+Besides relative positions there are lots of other relations between
+elements. Lilypond does not contain other specialized relation
+management (Like the relative positioning code). In stead, objects can
+be connected through dependencies, which sets the order in which objects
+are to be processed.
+
+Example: the direction of a beamed stem should equal the direction of
+the beam. When the stem is a added to the beam, a dependency on the
+beam is set in the stem: this means that @code{Beam::do_pre_processing
+()} (which does various direction related things) will be called before
+@code{Stem::do_pre_processing ()}.
+
+The code that manages dependencies resides in the class
+@code{Score_element}, a derived class of @code{Graphical_element}. The
+bulk of the code handles line breaking related issues.
+
+To sketch the problems with line breaking: suppose a slur spans a line
+break,
+@example
+
+c4( c'''' c | \break d d )d
+
+@end example
+In this case, the slur will appear as two parts, the first part spanning
+the first three notes (the @code{c}s), the second spanning the last
+three (the @code{d}s). Within Lilypond this is modeled as breaking the
+slur in parts: from the Original slur, two new clones of the old slur
+are made. Initially both clones depend on the six notes. After the
+hairy code in Score_element, Spanner and Item which does substitutions
+in sets of dependencies, the first clone depends on the first three
+notes, the second on the last three.
+
+The major derived classes of Score_element are Item and Spanner.
+An item has one horizontal position. A spanner hangs on two items.
+
+@node Items, , , Top
+@section Items
+
+
+
+An item is a score element that is associated with only one
+Paper_column. Examples are note heads, clefs, sup and superscripts, etc.
+Item is a derived class of Score_element.
+
+The shape of an item is known before the break calculations, and line
+spacing depends on the size of items: very wide items need more space
+than very small ones.
+
+An additional complication is the behavior of items at linebreaks. For
+example, when you do a time signature change, you get only one symbol.
+If it occurs at a linebreak, the new time signature must be printed both
+before and after the linebreak. Other `breakable symbols' such as
+clefs, and bar lines also exhibit this behavior.
+
+if a line of music is broken, the next line usually gets a clef. So in
+TeX terms, the clef is a postbreak. The same thing happens with meter
+signs: Normally the meter follows the bar. If a line is broken at that
+bar, the bar along with the meter stays on the "last" line, but the next
+line also gets a meter sign after the clef. To support this,
+breakable items are generated in the three versions: original
+(unbroken), left (before line break) and right (after line break).
+During the line spacing, these versions are used to try how the spacing
+of a line works out.
+
+Once the definitive spacing is determined, dependencies (and various
+other pointers) are substituted such that all dependencies point at the
+active items: either they point at the original, or they point at left
+and right.
+
+@node Spanners, , , Top
+@section Spanners
+
+Spanners are symbols that are of variable shape, eg. Slurs, beams, etc.
+Spanners is a derived class of Score_element.
+
+The final shape can only be determined after the line breaking process.
+All spanners are spanned on two items, called the left and right
+boundary item. The X reference point is the left boundary item.
+
+
+@node Future work, , , Top
+@section Future work
+
+There are plans to unify Spanner and Item, so there will no longer be
+such a clear distinction between the two. Right now, Score_elements are
+always either Item or either Spanner.
+
+Most of the properties of a graphic object are now member variables of
+the classes involved. To offer configurability, we want to move these
+variables to scheme (GUILE) variables, and no longer use C++ code to
+calculate them, but use Scheme functions.
+
+@node Coding standards, , , Top
+
+@chapter CodingStyle - standards while programming for GNU
+LilyPond
+
+Functions and methods do not return errorcodes.
+
+
+@unnumberedsubsec Languages
+
+C++ and Python are preferred. Perl is not. Python code should use an
+indent of 8, using TAB characters.
+
+@unnumberedsubsec Filenames
+
+Definitions of classes that are only accessed via pointers
+(*) or references (&) shall not be included as include files.
+
+filenames
+
+@example
+ ".hh" Include files
+ ".cc" Implementation files
+ ".icc" Inline definition files
+ ".tcc" non inline Template defs
+@end example
+
+in emacs:
+
+@example
+ (setq auto-mode-alist
+ (append '(("\\.make$" . makefile-mode)
+ ("\\.cc$" . c++-mode)
+ ("\\.icc$" . c++-mode)
+ ("\\.tcc$" . c++-mode)
+ ("\\.hh$" . c++-mode)
+ ("\\.pod$" . text-mode)
+ )
+ auto-mode-alist))
+@end example
+
+
+The class Class_name_abbreviation is coded in @file{class-name-abbr.*}
+
+@unnumberedsubsec Indentation
+
+Standard GNU coding style is used. In emacs:
+
+@example
+ (add-hook 'c++-mode-hook
+ '(lambda() (c-set-style "gnu")
+ )
+ )
+@end example
+
+If you like using font-lock, you can also add this to your @file{.emacs}:
+
+@example
+ (setq font-lock-maximum-decoration t)
+ (setq c++-font-lock-keywords-3
+ (append
+ c++-font-lock-keywords-3
+ '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
+ ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
+ ))
+@end example
+
+@unnumberedsubsec Classes and Types
+
+@example
+ This_is_a_class
+@end example
+
+@unnumberedsubsec Members
+
+@example
+ Class::member ()
+ Type Class::member_type_
+ Type Class::member_type ()
+@end example
+
+the @code{type} is a Hungarian notation postfix for @code{Type}. See below
+
+@unnumberedsubsec Macros
+
+Macros should be written completely in uppercase
+
+The code should not be compilable if proper macro declarations are not
+included.
+
+Don't laugh. It took us a whole evening/night to figure out one of
+these bugs, because we had a macro that looked like
+@code{DECLARE_VIRTUAL_FUNCTIONS ()}.
+
+@unnumberedsubsec Broken code
+
+Broken code (hardwired dependencies, hardwired constants, slow
+algorithms and obvious limitations) should be marked as such: either
+with a verbose TODO, or with a short "ugh" comment.
+
+@unnumberedsubsec Comments
+
+The source is commented in the DOC++ style. Check out doc++ at
+@uref{http://www.zib.de/Visual/software/doc++/index.html}
+
+@example
+
+ /*
+ C style comments for multiline comments.
+ They come before the thing to document.
+ [...]
+ */
+
+ /**
+ short description.
+ Long class documentation.
+ (Hungarian postfix)
+
+ TODO Fix boring_member ()
+ */
+ class Class @{
+ /**
+ short description.
+ long description
+ */
+
+ Data data_member_;
+
+ /**
+ short memo. long doco of member ()
+ @@param description of arguments
+ @@return Rettype
+ */
+ Rettype member (Argtype);
+
+ /// memo only
+ boring_member () @{
+ data_member_ = 121; // ugh
+ @}
+ @};
+
+@end example
+
+
+Unfortunately most of the code isn't really documented that good.
+
+@unnumberedsubsec Members (2)
+
+Standard methods:
+
+@example
+
+ ///check that *this satisfies its invariants, abort if not.
+ void OK () const
+
+ /// print *this (and substructures) to debugging log
+ void print () const
+
+ /**
+ protected member. Usually invoked by non-virtual XXXX ()
+ */
+ virtual do_XXXX ()
+
+ /**add some data to *this.
+ Presence of these methods usually imply that it is not feasible to this
+ via a constructor
+ */
+ add (..)
+
+ /// replace some data of *this
+ set (..)
+
+@end example
+
+@unnumberedsubsec Constructor
+
+Every class should have a default constructor.
+
+Don't use non-default constructors if this can be avoided:
+
+@example
+
+ Foo f(1)
+
+@end example
+
+is less readable than
+
+@example
+
+ Foo f;
+ f.x = 1
+
+@end example
+
+or
+
+@example
+
+ Foo f(Foo_convert::int_to_foo (1))
+
+@end example
+
+@unnumberedsec Hungarian notation naming convention
+
+Proposed is a naming convention derived from the so-called
+@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all
+uppercase, with the parts of the names separated by underscores.
+
+The hungarian notation is to be used when variables are not declared
+near usage (mostly in member variables and functions).
+
+@unnumberedsubsec Types
+
+@table @samp
+@item @code{byte}
+ unsigned char. (The postfix _by is ambiguous)
+@item @code{b}
+ bool
+@item @code{bi}
+ bit
+@item @code{ch}
+ char
+@item @code{f}
+ float
+@item @code{i}
+ signed integer
+@item @code{str}
+ string class
+@item @code{sz}
+ Zero terminated c string
+@item @code{u}
+ unsigned integer
+@end table
+
+@unnumberedsubsec User defined types
+
+@example
+
+ /** Slur blah. blah.
+ (slur)
+ */
+ class Slur @{@};
+ Slur* slur_p = new Slur;
+
+@end example
+
+@unnumberedsubsec Modifiers
+
+The following types modify the meaning of the prefix.
+These are preceded by the prefixes:
+
+@table @samp
+@item @code{a}
+ array
+@item @code{array}
+ user built array.
+@item @code{c}
+ const. Note that the proper order is @code{Type const}
+ i.s.o. @code{const Type}
+@item @code{C}
+ A const pointer. This would be equivalent to @code{_c_l}, but since any
+ "const" pointer has to be a link (you can't delete a const pointer),
+ it is superfluous.
+@item @code{l}
+ temporary pointer to object (link)
+@item @code{p}
+ pointer to newed object
+@item @code{r}
+ reference
+@end table
+
+@unnumberedsubsec Adjective
+
+Adjectives such as global and static should be spelled out in full.
+They come before the noun that they refer to, just as in normal english.
+
+@example
+
+foo_global_i: a global variable of type int commonly called "foo".
+
+@end example
+
+static class members do not need the static_ prefix in the name (the
+Class::var notation usually makes it clear that it is static)
+
+@table @samp
+@item @code{loop_i}
+ Variable loop: an integer
+@item @code{u}
+ Temporary variable: an unsigned integer
+@item @code{test_ch}
+ Variable test: a character
+@item @code{first_name_str}
+ Variable first_name: a String class object
+@item @code{last_name_ch_a}
+ Variable last_name: a @code{char} array
+@item @code{foo_i_p}
+ Variable foo: an @code{Int*} that you must delete
+@item @code{bar_i_l}
+ Variable bar: an @code{Int*} that you must not delete
+@end table
+
+Generally default arguments are taboo, except for nil pointers.
+
+The naming convention can be quite conveniently memorised, by
+expressing the type in english, and abbreviating it
+
+@example
+
+ static Array<int*> foo
+
+@end example
+
+@code{foo} can be described as "the static int-pointer user-array", so you get
+
+@example
+
+ foo_static_l_arr
+
+@end example
+
+
+@unnumberedsec Miscellaneous
+
+For some tasks, some scripts are supplied, notably creating patches, a
+mirror of the website, generating the header to put over cc and hh
+files, doing a release.
+
+Use them.
+
+@node Making patches, , , Top
+
+
+@unnumberedsec name
+
+
+PATCHES - track and distribute your code changes
+
+This page documents how to distribute your changes to GNU lilypond
+
+We would like to have unified context diffs with full pathnames. A
+script automating supplied with Lily.
+
+Distributing a change normally goes like this:
+
+@itemize @bullet
+@item make your fix/add your code
+@item Add changes to CHANGES, and add yourself to Documentation/topdocs/AUTHORS.texi
+@item generate a patch,
+@item e-mail your patch to one of the mailing lists
+ gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org
+@end itemize
+
+Please do not send entire files, even if the patch is bigger than the
+original. A patch makes it clear what is changed, and it won't
+overwrite previous (not yet released) changes.
+
+@unnumberedsec Generating a patch
+
+Simple version: run
+
+@example
+ make -C lilypond-x.y.z/ distclean
+ make -C lilypond-x.y.z.NEW/ distclean
+ diff -urN lilypond-x.y.z/ lilypond-x.y.z.NEW/
+@end example
+
+Complicated (but automated) version:
+
+In @file{VERSION}, set MY_PATCH_LEVEL:
+
+@example
+
+ VERSION:
+ ...
+ MY_PATCH_LEVEL=jcn1
+
+@end example
+
+In @file{CHANGES}, enter a summary of changes:
+
+@example
+ pl 0.1.73.jcn1
+ - added PATCHES.texi
+@end example
+
+Then, from the top of Lily's source tree, type
+
+@example
+ make release
+@end example
+
+These handy python scripts assume a directory structure which looks
+like:
+
+@example
+
+ lilypond -> lilypond-x.y.z # symlink to development directory
+ lilypond-x.y.z/ # current development
+ patches/ # patches between different releases
+ releases/ # .tar.gz releases
+
+@end example
+
+(Some scripts also assume this lives in @file{$HOME/usr/src}).
+
+
+@unnumberedsec Applying patches
+
+
+If you're following LilyPond development regularly, you probably want to
+download just the patch for each subsequent release.
+After downloading the patch (into the patches directory, of course), simply
+apply it:
+
+@example
+
+ gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E
+
+@end example
+
+and don't forget to make automatically generated files:
+
+@example
+
+ autoconf footnote(patches don't include automatically generated files,
+ i.e. file(configure) and files generated by file(configure).)
+
+ configure
+
+@end example
+
+
+@bye
+
+
--- /dev/null
+%-*-LaTeX-*-
+
+\documentclass{article}
+\usepackage{a4}
+\def\postMudelaExample{\setlength{\parindent}{1em}}
+\title{LilyPond, a Music Typesetter}
+\author{HWN}
+\usepackage{musicnotes}
+\usepackage{graphics}
+
+
+\begin{document}
+\maketitle
+
+[THIS IS WORK IN PROGRESS. THIS IS NOT FINISHED]
+
+% -*-LaTeX-*-
+\section{Introduction}
+
+The Internet has become a popular medium for collaborative work on
+information. Its success is partly due to its use of simple, text-based
+formats. Examples of these formats are HTML and \LaTeX. Anyone can
+produce or modify such files using nothing but a text editor, they are
+easily processed with run-of-the-mill text tools, and they can be
+integrated into other text-based formats.
+
+Software for processing this information and presenting these formats
+in an elegant form is available freely (Netscape, \LaTeX, etc.).
+Ubiquitousness of the software and simplicity of the formats have
+revolutionised the way people publish text-based information
+nowadays.
+
+In the field of performed music, where the presentation takes the form
+of sheet music, such a revolution has not started yet. Let us review
+some alternatives that have been available for transmitting sheet
+music until now:
+\begin{itemize}
+\item MIDI\cite{midi}. This format was designed for interchanging performances
+ of music; one should think of it as a glorified tape recorder
+ format. It needs dedicated editors, since it is binary. It does
+ not provide enough information for producing musical scores: some of
+ the abstract musical content of what is performed is thrown away.
+
+\item PostScript\cite{Postscript}. This format is a printer control
+ language. Printed musical scores can be transmitted in PostScript,
+ but once a score is converted to PostScript, it is virtually
+ impossible to modify the score in a meaningful way.
+
+\item Formats for various notation programs. Notation programs either
+ work with binary formats (e.g., NIFF\cite{niff-web}), need specific
+ platforms (e.g., Sibelius\cite{sibelius}), are proprietary or
+ non-portable tools themselves (idem), produce inadequate output
+ (e.g., MUP\cite{mup}), are based on graphical content (e.g.,
+ MusixTeX\cite{musixtex1}), limit themselves to specific subdomains
+ (e.g., ABC\cite{abc2mtex}), or require considerable skill and
+ knowledge to use (e.g., SCORE\cite{score})
+
+\item SMDL\cite{smdl-web}. This is a very rich ASCII format, that is
+ designed for storing many types of music. Unfortunately, there is
+ no implementation of a program to print music from SMDL available.
+ Moreover, SMDL is so verbose, that it is not suitable for human
+ production.
+
+\item TAB\cite{tablature-web}. Tab (short for tablature) is a popular
+ format, for interchanging music over e-mail, but it can only be used
+ for guitar music.
+\end{itemize}
+
+In summary, sheet music is not published and edited on a wide scale
+across the internet because no format for music
+interchange exists that is:
+\begin{itemize}
+\item open, i.e., with publically available specifications.
+\item based on ASCII, and therefore suitable for human consumption and
+ production.
+\item rich enough for producing publication quality sheet music from
+ it.
+\item based on musical content (unlike, for example, PostScript), and
+ therefore suitable for making modifications.
+\item accompanied by tools for processing it that are freely available
+ across multiple platforms.
+\end{itemize}
+
+
+With the creation of LilyPond, we have tried to create both a
+convenient format for storing sheet music, and a portable,
+high-quality implementation of a compiler, that compiles the input
+into a printable score. You can find a small example of LilyPond
+input along with output in Figure~\ref{fig:intro-fig}.
+%
+\begin{figure}[htbp]
+ \begin{center}
+\begin[verbatim]{mudela}
+ \score {
+ \notes
+ \context GrandStaff <
+ \transpose c'' { c4 c4 g4 g4 a4 a4 g2 }
+ { \clef "bass"; c4 c'4
+ \context Staff <e'2 {\stemdown c'4 c'4}> f'4 c'4 e'4 c'4 }
+ >
+ \paper {
+ linewidth = -1.0\cm ;
+ }
+ }
+\end{mudela}
+ \caption{A small example of LilyPond input}
+ \label{fig:intro-fig}
+ \end{center}
+\end{figure}
+%
+
+
+The input language encodes musical events (such as notes and rests) on
+the basis of their time-ordering. For example, the grammar includes
+constructs that specify that notes start simultaneous and that notes
+are to be played in sequence. In this encoding some context that is
+present in sheet music is lost.
+
+The compiler reconstructs the notation from the encoded music. Its
+operation comprises four different steps (see
+Figure~\ref{fig:intro-steps}).
+
+\begin{description}
+\item[Parsing] During parsing, the input is converted in a syntax tree.
+
+\item[Interpreting] In the \emph{interpreting} step, it is determined
+ which symbols have to be printed. Objects that correspond to
+ notation (\emph{Graphical objects}) are created from the syntax tree
+ in this phase. Generally speaking, for every symbol printed there is
+ one graphical object. These objects are incomplete: their position
+ and their final shape is unknown.
+
+ The context that was lost by encoding the input in a language is
+ reconstructed during this conversion.
+\item[Formatting] The next step is determing where symbols are to be
+ placed, this is called \emph{formatting}.
+\item[Outputting]
+ Finally, all Graphical objects are outputted as PostScript or \TeX\ code.
+\end{description}
+
+\def\staffsym{\vbox to 16pt{
+ \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
+ \vfil
+ \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
+ \vfil
+ \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
+ \vfil
+ \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
+ \vfil
+ \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip
+}}
+
+\def\vspacer{\vbox to 20pt{\vss}}
+\begin{figure}[h]
+\def\spacedhbox#1{\hbox{\ #1\ }}
+\begin{eqnarray*}
+ {\spacedhbox{Input}\atop \hbox{\texttt{\{c8 c8\}}}} {\spacedhbox{Parsing}\atop\longrightarrow}
+ {\spacedhbox{Syntax tree}\atop\spacedhbox{\textsf{Sequential(Note,Note)}}}
+ {\spacedhbox{Interpreting}\atop\longrightarrow}\\
+ \vspacer\\
+ {\spacedhbox{Graphic objects}\atop\spacedhbox{\texttrebleclef \textquarterhead\texteighthflag\textquarterhead\texteighthflag \staffsym }}
+ {\spacedhbox{Formatting}\atop\longrightarrow}
+ {\spacedhbox{Formatted objects}\atop\hbox{
+ \mudela{c''8 c''8}
+ }}\\
+\vspacer\\
+ {\spacedhbox{Outputting}\atop\longrightarrow}
+ {\spacedhbox{PostScript code}\atop\hbox{\texttt{\%!PS-Adobe}\ldots}}
+\end{eqnarray*}
+ \caption{Parsing, Interpreting, Formatting and Outputting}
+ \label{fig:intro-steps}
+\end{figure}
+
+
+The second step, the interpretation phase of the compiler, can be
+manipulated as a separate entity: the interpretation process is
+composed of many separate modules, and the behaviour of the modules is
+parameterised. By recombining these interpretation modules,
+and changing parameter settings, the same piece of music can be
+printed differently, as is shown in Figure~\ref{fig:intro-interpret}.
+
+This makes it easy to extend the program. Moreover, this enables the
+same music to be printed in different versions, e.g., in a conductors
+score and in extracted parts.
+
+
+\begin{figure}[h]
+ \begin{center}
+ \begin{mudela}
+ \score {
+ \notes
+ \context GrandStaff <
+ \transpose c'' { c4 c4 g4 g4 a4 a4 g2 }
+ { \clef "bass"; c4 c'4
+ \context Staff <e'2 {\stemdown c'4 c'4}> f'4 c'4 e'4 c'4 }
+ >
+ \paper {
+ linewidth = -1.0\cm ;
+ \translator {
+ \VoiceContext
+ \remove "Stem_engraver";
+ }
+ \translator {
+ \StaffContext
+ numberOfStaffLines = 3;
+ }
+ }
+ }
+ \end{mudela}
+ \caption{The interpretation phase can be manipulated: the same
+ music as in Figure~\ref{fig:intro-fig} is interpreted
+ differently: three staff lines and no stems.}
+ \label{fig:intro-interpret}
+ \end{center}
+\end{figure}
+
+
+
+\section{Preliminaries}
+
+To understand the rest of the article, it is necessary to know
+something about music notation and music typography. Since both
+communicate music, we will explain some characteristics of instruments
+and western music that motivate some notational constructs.
+
+\subsection{Music}
+
+Music notation is meant to be read by human performers. They sing or
+play instruments that can produce sounds of different pitches. These
+sounds are called \emph{notes}. Additionally, the sounds can be
+articulated in differents ways, e.g., staccato (short and separated)
+or legato (fluently bound together). The loudness of the notes can
+also be varied. Changes in loudness are called \emph{dynamics}.
+
+Silence is also an element of music. The musical terminology for
+silence within music is \emph{rest}.
+
+The basic unit of pitch is the \emph{octave}. The octave corresponds
+to a frequency ratio of 1:2. For example the pitch denoted by a'
+(frequency: 440 hertz) is one octave lower than a'' (frequency: 880
+hertz). Various instruments have a limited \emph{pitch range}, for
+example, a trumpet has a range of about 2.5 octaves. Not all
+instruments have ranges in the same register: a tuba also has a range
+of 2.5 octaves, but the range of the tuba is much lower.
+
+Musicology has a confusing mix of relative and absolute measures for
+pitches: the term `octave' refers to both a difference between two
+pitches (the frequency ratio of 1:2), and to a range of pitches. For
+example, the term `[eengestreept] octave' refers to the pitch range
+between 261.6 Hz and 523.3 Hz.
+
+
+The octave is divided into smaller pitch steps. In modern western
+music, every octave is divided into twelve approximately equidistant
+pitch steps, and each step is called a \emph{semitone}. Usually, the
+pitches in a musical piece come from a smaller subset of these twelve
+possible pitches. This smaller subset along with the musical
+functions fo the pitches is called the
+\emph{tonality}\footnote{Tonality also refers to the relations between
+ and functions of certain pitches. Since these do not have any
+ impact on notation, we ignore this} of the piece.
+
+
+The standard tonality that forms the basis of music notation
+(the key of C major) is a set of seven pitches within every octave.
+Each of these seven is denoted by a name. In English, these are names
+are (in rising pitch) denoted by c, d, e, f, g, a and b. Pitches that
+are a semitone higher or lower than one of these seven can be
+represented by suffixing the name with `sharp' or `flat'
+respectively (this is called an \emph{chromatic alteration}).
+
+A pitch therefore can be fully specified by a combination of the
+octave number, the note name and a chromatic alteration.
+Figure~\ref{fig:intro-pitches} shows the relation between names and
+frequencies.
+
+
+
+
+\begin{figure}[h]
+ \begin{center}
+ [te doen]
+ \end{center}
+ \caption{Pitches in western music. The octave number is denoted
+ by a superscript.}
+ \label{fig:intro-pitches}
+\end{figure}
+
+
+Many instruments can produce more than one note at the same time, e.g.
+pianos and guitars. When more notes are played simultaneously, they
+form a so-called \emph{chord}.
+
+The unit of duration is the \emph{beat}. When playing, the tempo is
+determined by setting the number of beats per minute. In western
+music, beats are often stressed in a regular pattern: for example
+Waltzes have a stress pattern that is strong-weak-weak, i.e. every
+note that starts on a `strong' beat is louder and has more pronounced
+articulation. This stress pattern is called \emph{meter}.
+
+\subsection{Music notation}
+
+Music notation is a system that tries to represent musical ideas
+through printed symbols. Music notation has no precise definition,
+but most conventions have described in reference manuals on music
+notation\cite{read-notation}.
+
+In music notation, sounds and silences are represented by symbols that
+are called note and rest respectively.\footnote{These names serve a
+ double purpose: the same terms are used to denote the musical
+ concepts.} The shape of notes and rests indicates their duration
+(See figure~\ref{noteshapes}) relative to the whole note.
+
+
+\begin{figure}[h]
+ \begin{center}
+\begin{mudela}
+ \score {
+ \notes \transpose c''{ c\longa*1/4 c\breve*1/2 c1 c2 c4 c8 c16 c32 c64 }
+ \paper {
+ \translator {
+ \StaffContext
+ \remove "Staff_symbol_engraver";
+ \remove "Time_signature_engraver";
+% \remove "Bar_engraver";
+ \remove "Clef_engraver";
+ }
+linewidth = -1.;
+ }
+}
+\end{mudela}
+\begin{mudela}
+ \score {
+ \notes \transpose c''\context Staff { r\longa*1/4 r\breve*1/2 r1 r2 r4 r8 r16 r32 r64 }
+ \paper {
+ \translator {
+ \StaffContext
+ \remove "Staff_symbol_engraver";
+ \remove "Time_signature_engraver";
+% \remove "Bar_engraver";
+ \remove "Clef_engraver";
+ }
+ linewidth = -1.;
+ }
+}
+\end{mudela}
+ \caption{Note and rest shapes encode the length. At the top notes
+ are shown, at the bottom rests. From left to right a quadruple
+ note (\emph{longa}), double (\emph{breve}), whole, half,
+ quarter, eigth, sixteenth, thirtysecond and sixtyfourth. Each
+ note has half of the duration of its predecessor.}
+ \label{fig:noteshapes}
+\end{center}
+\end{figure}
+
+
+Notes are printed in a grid of horizontal lines called \emph{staff} to
+denote their pitch: each line represents the pitch of from the
+standard scale (c, d, e, f, g, a, b). The reference point is the
+\emph{clef}, eg., the treble clef marks the location of the $g^1$
+pitch. The notes are printed in their time order, from left to right.
+
+
+\begin{figure}[h]
+ \begin{center}
+ \begin{mudela}
+ \score { \notes {
+ a4 b c d e f g a \clef bass;
+ a4 b c d e f g a \clef alto;
+ a4 b c d e f g a \clef treble;
+ }
+ \paper { linewidth = 15.\cm; }
+ }
+ \end{mudela}
+ \caption{Pitches ranging from $a, b, c',\ldots a'$, in different
+ clefs. From left right the bass, alto and treble clef are
+ featured.}
+ \label{fig:pitches}
+ \end{center}
+\end{figure}
+
+The chromatic alterations are indicated by printing a flat sign or a
+sharp sign in front of the note head. If these chromatic alterations
+occur systematically (if they are part of the tonality of the piece),
+then this indicated with a \emph{key signature}. This is a list of
+sharp/flat signs which is printed next to the clef.
+
+Articulation is notated by marking the note shapes wedges, hats and
+dots all indicate specific articulations. If the notes are to be
+bound fluently (legato), the note shapes are encompassed by a smooth
+curve called \emph{slur},
+
+\begin{figure}[h]
+ \begin{center}
+ \begin{mudela}
+ c'4-> c'4-. g'4 ( b'4 ) g''4
+ \end{mudela}
+ \caption{Some articulations. From left to right: extra stress
+ (\emph{marcato}), short (staccato), slurred notes (legato).}
+ \label{fig:articulation}
+ \end{center}
+\end{figure}
+
+
+
+Dynamics are notated in two ways: absolute dynamics are indicated by
+letters: \textbf{f} (from Italian ``forte'') stands for loud,
+\textbf{p} (from Italian ``piano'') means soft. Gradual changes in
+loudness are notated by (de)crescendos. These are hairpin like shapes
+below the staff.
+
+\begin{figure}[h]
+ \begin{center}
+ \begin{mudela}
+ g'4\pp \< g'4 \! g'4 \ff \> g'4 g' \! g'\ppp
+ \end{mudela}
+ \caption{Dynamics: start very soft (pp), grow to loud (ff) and
+ decrease to extremely soft (ppp)}
+ \label{fig:dynamics}
+ \end{center}
+\end{figure}
+
+
+The meter is indicated by barlines: every start of the stress pattern
+is preceded by a vertical line, the \emph{bar line}. The space
+between two bar lines is called measure. It is therefore the unit of
+the rhythmic pattern.
+
+The time signature also indicates what kind of rhythmic pattern is
+desired. The time signature takes the form of two numbers stacked
+vertically. The top number is the number of beats in one measure, the
+bottom number is the duration (relative to the whole note) of the note
+that takes one beat. Example: 2/4 time signature means ``two beats
+per measure, and a quarter note takes one beat''
+
+Chords are written by attaching multiple note heads to one stem. When
+the composer wants to emphasize the horizontal relationships between
+notes, the simultaneous notes can be written as voices (where every
+note head has its own stem). A small example is given in
+Figure~\ref{fig:simultaneous}.
+
+\begin{figure}[h]
+ \begin{center}
+ \begin{mudela}
+ \relative c'' {\time 2/4; <c4 e> <d f>
+ \context Staff < \context Voice = VA{
+ \stemdown
+ c4 d
+ b16 b b b b b b b }
+ \context Voice = VB {
+ \stemup e4 f g8 g4 g8 } >
+ }
+ \end{mudela}
+ \caption{Notes sounding together. Chord notation (left, before
+ the bar line) emphasizes vertical relations, voice notation
+ emphasizes horizontal relations. Separate voices needn't have
+ synchronous rhythms (third measure).
+ }
+ \label{fig:simultaneous}
+ \end{center}
+\end{figure}
+
+Separate voices do not have to share one rhythmic pattern---this is
+also demonstrated in Figure~\ref{fig:simultaneous}--- they are in a sense%vaag
+independent. A different way to express this in notation, is by
+printing each voice on a different staff. This is customary when
+writing for piano (both left and right hand have a staff of their own)
+and for ensemble (every instrument has a staff of its own).
+
+
+
+\subsection{Music typography}
+
+Music typography is the art of placing symbols in esthetically
+pleasing configuration. Little is explicitly known about music
+typography. There are only a few reference works
+available\cite{ross,wanske}. Most of the knowledge of this art has
+been transmitted verbally, and was subsequently lost.
+
+The motivation behind choices in typography is to represent the idea
+as clearly as possible. Among others, this results in the following
+guidelines:
+\begin{itemize}
+\item The printed score should use visual hints to accentuate the
+ musical content
+\item The printed score should not contain distracting elements, such
+ as large empty regions or blotted regions.
+\end{itemize}
+
+An example of the first guideline in action is the horizontal spacing.
+The amount of space following a note should reflect the duration of
+that note: short notes get a small amount of space, long notes larger
+amounts. Such spacing constraints can be subtle, for the
+``amount of space'' is only the impression that should be conveyed; there
+has to be some correction for optical illusions. See
+Figure~\ref{fig:spacing}.
+
+\begin{figure}[h]
+ \begin{center}
+ \begin{mudela}
+ \relative c'' { \time 3/4; c16 c c c c8 c8 | f4 f, f' }
+ \end{mudela}
+ \caption{Spacing conveys information about duration. Sixteenth
+ notes at the left get less space than quarter notes in the
+ middle. Spacing is ``visual'', there should be more space
+ after the first note of the last measure, and less after second. }
+ \label{fig:spacing}
+ \end{center}
+\end{figure}
+
+Another example of music typography is clearly visible in collisions.
+When chords or separate voices are printed, the notes that start at
+the same time should be printed aligned (ie., with the same $x$
+position). If the pitches are close to each other, the note heads
+would collide. To prevent this, some notes (or note heads) have to be
+shifted horizontally. An example of this is given in
+Figure~\ref{fig:collision}.
+\begin{figure}[h]
+ \begin{center}
+ [todo]
+ \caption{Collisions}
+ \label{fig:collision}
+ \end{center}
+\end{figure}
+
+\bibliographystyle{hw-plain}
+\bibliography{engraving,boeken,colorado,computer-notation,other-packages}
+
+\section{Requirements}
+
+
+\section{Approach}
+
+\subsection{Input}
+
+The input format consists of combining a symbolic representation of
+music with style sheet that describes how the symbolic presentation
+can converted to notation. The symbolic representation is based on a
+context free language called \textsf{music}. Music is a recursively
+defined construction in the input language. It can be constructed by
+combining lists of \textsf{music} sequentially or parallel or from
+terminals like notes or lyrics.
+
+The grammar for \textsf{music} is listed below. It has been edited to
+leave out the syntactic and ergonomic details.
+
+\begin{center}
+ \begin{tabular}{ll}
+Music: & SimpleMusic\\
+ & $|$ REPEATED int Music ALTERNATIVE MusicList\\
+ & $|$ SIMULTANEOUS MusicList\\
+ & $|$ SEQUENTIAL MusicList\\
+ & $|$ CONTEXT STRING '=' STRING Music\\
+ & $|$ TIMES int int Music \\
+ & $|$ TRANSPOSE PITCH Music \\
+SimpleMusic: & $|$ Note\\
+ & $|$ Lyric\\
+ & $|$ Rest\\
+ & $|$ Chord\\
+ & $|$ Command\\
+Command: & METERCHANGE\\
+ & $|$ CLEFCHANGE\\
+ &$|$ PROPERTY STRING '=' STRING\\
+Chord: &PitchList DURATION\\
+Rest: &REST DURATION\\
+Lyric: &STRING DURATION\\
+Note: &PITCH DURATION\\
+\end{tabular}
+\end{center}
+
+The terminals are both purely musical concepts that have a duration,
+and take a non-zero amount of musical time, like notes and lyrics, and
+commands that behave as if they have no duration.\footnote{The
+ PROPERTY command is a generic mechanism for controlling the
+ interpretation, i.e. the musical style sheets. See [forward ref]}
+
+The nonterminal productions can
+\begin{itemize}
+\item Some productions combine multiple elements: one can specify that
+ element are to be played in sequence, simultaneously or repetitively.
+\item There are productions for transposing music, and for dilating
+ durations of music: the TIMES production can be used to encode a
+ triplet.\footnote{A triplet is a group of three notes marked by a
+ bracket, that are played 3/2 times faster.}
+\item
+ There are productions that give directions to the interpretation
+ engine (the CONTEXT production)
+\end{itemize}
+
+
+\section{Context in notation}
+
+Music notation relies heavily on context. Notational symbols do not
+have meaning if they are not surrounded by other context elements. In
+this section we give some examples how the reader uses this context do
+derive meaning of a piece of notation. We will focus on the prime
+example of context: the staff.
+
+A staff is the grid of five horizontal lines, but it contains more components :
+\begin{itemize}
+\item A staff can have a key signature (printed at the left)
+\item A staff can have a time signature (printed at the left)
+\item A staff has bar lines
+\item A staff has a clef (printed at the left)
+\end{itemize}
+
+It is still possible to print notes without these components, but one
+cannot determine the meaning of the notes.
+\begin{mudela}
+\score{
+\notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+\paper {
+ linewidth = -1.;
+ \translator {
+ \StaffContext
+ \remove "Time_signature_engraver";
+% \remove "Bar_engraver";
+ \remove "Staff_symbol_engraver";
+ \remove "Clef_engraver";
+ \remove "Key_engraver";
+ }
+ }
+}
+\end{mudela}
+
+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 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. Adding barlines helps with finding the strong
+and weak beats.
+\begin{mudela}
+\score {
+ \notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+ \paper{
+ linewidth = -1.;
+\translator{
+ \StaffContext
+ \remove "Staff_symbol_engraver";
+ \remove "Clef_engraver";
+ \remove "Key_engraver";}
+ }
+ }
+\end{mudela}
+
+It is impossible to deduce the exact pitch of the notes. One needs a
+clef to do so. Staff lines help the eye in determining the vertical
+position of a note wrt. to the clef.
+\begin{mudela}
+\score {
+ \notes \relative c' {\clef alto; \time 2/4; g'4 c,4 a'4 f4 e c d2 }
+ \paper {
+ linewidth = -1.;
+ }
+}
+\end{mudela}
+
+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!
+
+
+\section{Interpretation context}
+
+Context (clef, time signature etc.) determines the relationship
+between musical and its notation in notes. Because LilyPond writes
+notation, context works the other way around for LilyPond: with
+context a piece of music can be converted to notation.
+
+A reader remembers this context while reading the notation from left
+to right. By analogy, LilyPond constructs this context while
+constructing notes from left to right. This is what happens in the
+``Interpretation'' phase from~\ref{fig:intro-fig}. In LilyPond, the
+state of this context is a set of variables with their values; A staff
+context contains variables like
+
+\begin{itemize}
+\item current clef
+\item current time signature
+\item current key
+\end{itemize}
+
+These variables determine when and how clefs, time signatures, bar
+lines and accidentals are printed.
+
+
+Staff is not the only form of context in notation. In polyphonic
+music, the stem direction shows which notes form a voice: all notes of
+the same voice have stems pointing in the same direction. The value
+of this variable determines the appearance of the printed stems.
+
+In LilyPond ``Notation context'' is abstracted to a data structure
+that is used, constructed and modified during the interpretation
+phase. It contains context properties, and is responsible for
+creating notational elements: the staff context creates symbols for
+clefs, time signatures and key signatures. The Voice context creates
+stems, note heads.
+
+For the fragment of polyphonic music below,
+\begin{mudela}
+ \context Staff { c'4 < { \stemup c'4 } \context Voice = VB { \stemdown a4 } > }
+\end{mudela}
+A staff context is created. Within this staff context (which printed
+the clef), a Voice context is created, which prints the first note.
+Then, a second Voice context is created, with stem direction set to
+``up'', and the direction for the other is set to down. Both Voice
+contexts are still part of the same Staff context.
+
+In the same way, multiple staff scores are created: within the score
+context, multiple staff contexts are created. Every staff context
+creates the notation associated with a staff.
+
+\section{Discussion}
+
+
+
+\end{document}
+
+The complexity of music notation was tackled by adopting a modular
+design: both the formatting system (which encodes the esthetic rules of
+notation), and the interpretation system (which encodes the semantic
+rules) are highly modular.
+
+
+The difficulty in creating a format for music notation is rooted in
+the fact that music is multi dimensional: each sound has its own
+duration, pitch, loudness and articulation. Additionally, multiple
+sounds may be played simultaneously. Because of this, there is no
+obvious way to ``flatten'' music into a context-free language.
+
+The difficulty in creating a printing engine is rooted in the fact
+that music notation complicated: it is very large graphical
+``language'' with many arbitrary esthetic and semantic conventions.
+Building a system that formats full fledged musical notation is a
+challenge in itself, regardless of whether it is part of a compiler or
+an editor.
+
+The fact that music and its notation are of a different nature,
+implies that the conversion between input notation is non-trivial.
+
+In LilyPond we solved the above problem in the following way:
+
--- /dev/null
+
+\input lilyponddefs
+
+\def\fetdef#1#2{%
+ \def#1{\hbox{\char#2}}}
+
+% huh? from where
+\input feta20.sty
+
+\font\fetasixteenfont=feta16
+\font\fetaelevenfont=feta11
+\def\fetafont{\fetasixteenfont}
+
+\newdimen\ild
+\ild=4pt
+\newdimen\stemthick
+\stemthick=0.4pt
+
+\def\eighthstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt\raise
+ 3.5ex\hbox{\eighthflag}}}
+\def\texteighthflag{{\fetafont\raise 0ex\hbox{\fetafont\eighthflag}}}
+\def\textdeighthflag{{\fetafont\raise 0ex\hbox{\deighthflag}}}
+
+\def\texteighthnote{{\hbox{\hbox{\fetafont\quartball}\kern
+ -0.5\stemthick\eighthstem}}}
+\def\quarterstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt}}
+\def\textquarterstem{\quarterstem}
+\def\textchord{{\hbox{\fetafont\lower.5ex\hbox to
+ 0pt{\textquarterhead}\raise.5ex\hbox{\textquarterhead}\kern
+ -0.5\stemthick\eighthstem}}}
+\def\textbassclef{\hbox{\fetafont\bassclef}}
+\def\texttrebleclef{\hbox{\fetafont\trebleclef}}
+\def\textslur{\embeddedps{9.378744 -3.171539 3.923099 -3.171539 0.000000 0.000000 12.800000 0.000000 3.672177 -3.672177 9.127823 -3.672177 12.800000 0.000000 0.000000 0.000000 draw_slur}}
+
+\def\textmarcato{{\fetafont\raise 1ex\hbox{\hskip 1ex\sforzatoaccent}}}
+
+
+\def\textquarterhead{\hbox{\fetafont\raise 2.5pt\hbox{\quartball}}}
+\def\texteighthstem{\hbox{\lower 5pt\hbox{\eighthstem}}}
+\def\texthalfnote{{\hbox{\hbox{\fetafont\halfball}\kern -0.5\stemthick\quarterstem}}}
+\def\textquarternote{{\hbox{\hbox{\fetafont\quartball}\kern -0.5\stemthick\quarterstem}}}
+\def\textflat{{\fetafont\raise 1ex\hbox{\flat}}}
+\def\textsharp{{\fetafont\raise1ex\hbox{\sharp}}}
--- /dev/null
+\input texinfo @c -*-texinfo-*- vim:tw=72
+@setfilename regression-test.info
+@settitle LilyPond Regression test
+
+@c fool ls-latex
+@ignore
+@author Han-Wen Nienhuys and Jan Nieuwenhuizen
+@title LilyPond Regression test
+@end ignore
+
+@node Top, , ,
+
+@section Introduction
+
+This document tries give an brief overview of LilyPond features. When
+the text correspond with the shown notation, we consider LilyPond
+Officially BugFree (tm). This document is intended for finding bugs,
+and documenting bugfixes.
+
+@section Notes and rests
+
+Rests. Note that the dot of 8th, 16th and 32nd rests rest should be
+next to the top of the rest. All rests except the whole rest are
+centered on the middle staff line.
+
+@mudelafile{rest.fly}
+
+Note head shapes are settable. The stem endings should be adjusted
+per note head. If you want different note head styles on one stem,
+you must create a special context called Thread.
+
+@mudelafile{noteheadstyle.ly}
+
+Noteheads can have dots, and ---although this is bad style in duple
+meters--- rests can too. Augmentation dots should never be printed on
+a staff line, but rather be shifted vertically. They should go up, but
+in case of multiple parts, the down stems have down shifted dots.
+(Wanske p. 186) In case of chords, all dots should be in a column.
+The dots go along as rests are shifted to avoid collisions.
+
+@mudelafile{dots.fly}
+
+Multiple measure rests do not collide with barlines and clefs. They
+are not expanded when you set @code{Score.SkipBars}. Although the
+multi-measure-rest is a Spanner, minimum distances are set to keep it
+colliding from barlines.
+
+@mudelafile{multi-measure-rest.ly}
+
+@section Stems
+
+Stem tremolos (official naming?) or rolls are tremolo signs that look
+like beam segments crossing stems. If the stem is in a beam, the
+tremolo must be parallel to the beam. If the stem is invisible
+(eg. on a whole note), the tremolo must be centered on the note.
+
+@mudelafile{stem-tremolo.ly}
+
+Chord tremolos look like beams, but are a kind of repeat symbol.
+To avoid confusion, chord tremolo beams do not reach the stems, but
+leave a gap. Chord tremolo beams on half notes are not ambiguous,
+as half notes cannot appear in a regular beam, and should reach the
+stems.
+
+@mudelafile{chord-tremolo.sly}
+
+Beams, stems and noteheads often have communication troubles, since
+the two systems for y dimensions (1 unit = staffspace, 1 unit = 1
+point) are mixed.
+
+Stems, beams, ties and slurs should behave similarly, when placed
+on the middle staff line. Of course stem-direction is down for high
+notes, and up for low notes.
+
+@mudelafile{stem-direction.sly}
+
+Similarly, if @code{stem_default_neutral_direction} is set to @code{-1}.
+
+@mudelafile{stem-direction-down.ly}
+
+@section Scripts
+
+The staccato dot (and all scripts with follow-into-staff set), must
+not be on staff lines.
+
+@mudelafile{staccato-pos.sly}
+
+@section Grace notes
+
+Grace notes are typeset as an encapsulated piece of music. You can
+have beams, notes, chords, stems etc. within a @code{\grace} section.
+Slurs that start within a grace section, but aren't ended are attached
+to the next normal note. Grace notes have zero duration. If there
+are tuplets, the grace notes won't be under the brace. Grace notes
+can have accidentals, but they are (currently) spaced at a fixed
+distance. Grace notes (of course) come before the accidentals of the
+main note. Grace notes can also be positioned after the main note.
+
+@mudelafile{grace.ly}
+
+
+@section Beams, slurs and other spanners
+
+Beaming is generated automatically. Beams may cross bar lines. In that
+case, line breaks are forbidden. Yet clef and key signatures are
+hidden just as with breakable bar lines.
+
+@mudelafile{beaming.ly}
+
+Beams should behave reasonably well, even under extreme circumstances.
+Stems may be short, but noteheads should never touch the beam.
+
+@mudelafile{beam-extreme.ly}
+
+Beams should always reach the middle staff line, the second beam
+counting from the note head side, should never be lower than the
+second staff line. This does not hold for grace note beams.
+
+@mudelafile{beam-position.sly}
+
+Slurs should look nice and symmetric. The curvature may increase
+only to avoid noteheads, and as little as possible.
+
+@mudelafile{slur-symmetry.ly}
+@mudelafile{slur-symmetry-1.ly}
+
+Ties are strictly horizontal. They are placed in between note heads.
+The horizontal middle should not overlap with a staffline.
+
+@mudelafile{tie.ly}
+
+Beams can be typeset over fixed distance aligned staffs, beam
+beautification doesn't really work, but knees do. Beams should be
+behave well, wherever the switching point is.
+
+@mudelafile{beam-cross-staff.ly}
+
+The same goes for slurs. They behave decently when broken across
+linebreak.
+
+@mudelafile{slur-cross-staff.ly}
+
+Tuplets are indicated by a bracket with a number. There should be no
+bracket if there is one beam that matches the length of the tuplet.
+The bracket does not interfere with the stafflines, and the number is
+centered in the gap in the bracket.
+
+@mudelafile{tup.ly}
+
+@section Repeats
+
+LilyPond has three modes for repeats: folded, unfolded and
+semi-unfolded. Unfolded repeats are fully written out. Semi unfolded
+repeats have the body written and all alternatives sequentially.
+Folded repeats have the body written and all alternatives
+simultaneously. If the number of alternatives is larger than the
+repeat count, the excess alternatives are ignored. If the number of
+alternatives is smaller, the first alternative is multiplied to get to
+the number of repeats.
+
+Unfolded behavior:
+
+@mudelafile{repeat-unfold.ly}
+
+Volta (Semi folded) behavior. Voltas can start on non-barline moments.
+If they don't barlines should still be shown.
+
+@mudelafile{repeat-volta.ly}
+
+Folded. This doesn't make sense without alternatives, but it works.
+
+@mudelafile{repeat-fold.ly}
+
+@section Lyrics
+
+Lyrics can be set to a melody automatically. Excess lyrics will be
+dumped. Lyrics will not be set over rests. You can have melismata
+either by setting a property melismaBusy, or by setting
+automaticMelismas (which will set melismas during slurs and ties). If
+you want a different order than first Music, then Lyrics, you must
+precook a chord of staffs/lyrics and label those. Of course
+@code{\rhythm} ignores any other rhythms in the piece. Hyphens and
+extenders do not assume anything about lyric lengths, so they continue
+to work.
+
+@mudelafile{lyric-combine.ly}
+
+@section Multiple notes
+
+Rests should not collide with beams, stems and noteheads. Rests may
+be under beams. Rests should be move by integral number of spaces
+inside the staff, and by half spaces outside. Notice that the half
+and whole rests just outside the staff get ledger lines in different
+cases.
+
+@mudelafile{rest-collision.ly}
+
+Normal collisions. We have support for polyphony, where the
+middle voices are horizontally shifted.
+
+@mudelafile{collisions.ly}
+
+The number of stafflines of a staff can be set with the property
+numberOfStaffLines. Ledger lines both on note heads and rests are
+adjusted. Barlines also are adjusted.
+
+
+@mudelafile{number-staff-lines.fly}
+
+@section Spacing
+
+In a limited number of cases, LilyPond corrects for optical spacing
+effects. In this example, space for opposite pointed stems is adjusted
+
+@mudelafile{stem-spacing.sly}
+
+If there are accidentals in the music, we add space, but the space
+between note and accidentals is less than between the notes with the
+same value. Clef changes also get extra space, but not as much as
+barlines.
+
+
+Even if a line is very tightly spaced, there will still be room
+between prefatory matter and the following notes. The space after the
+prefatory is very rigid. In contrast, the space before the barline
+must stretch like the space within the measure.
+
+Tight:
+
+@mudelafile{spacing-tight.ly}
+
+Natural:
+
+@mudelafile{spacing-natural.ly}
+
+Loose:
+
+@mudelafile{spacing-loose.ly}
+
+Adding a @code{Bar_engraver} to the LyricsVoice context makes sure that
+lyrics don't collide with barlines.
+
+@mudelafile{lyrics-bar.ly}
+
+@section Global stuff
+
+Breaks can be encouraged and discouraged using @code{\break} and
+@code{\nobreak}. They are abbrevs for @code{\penalty} commands.
+
+@mudelafile{break.ly}
+
+
+Markings that are attached to (invisible) barlines are
+delicate: the are attached to the rest of the score without the score
+knowing it. Consequently, they fall over often.
+
+@mudelafile{bar-scripts.ly}
+
+Staff margins are also markings attached to barlines. They should be
+left of the staff, and be centered vertically wrt the staff. They may
+be on normal staffs, but also on compound staffs, like the PianoStaff
+
+@mudelafile{staff-margin.ly}
+
+Breathing signs, also used for phrasing, do normally not influence
+global spacing -- only if space gets tight, notes are shifted to make
+room for the breathing sign. Breathing signs break beams running
+through their voice. In the following example, the notes in the first
+two measures all have the same distance from each other:
+
+@mudelafile{breathing-sign.ly}
+
+Fonts are available in a default set of sizes: 11, 13, 16, 20, 23 and
+26pt staffheight. Sizes of the text fonts and symbol fonts are made
+to match the staff dimensions.
+
+@mudelafile[nofly]{size11.ly}
+
+@mudelafile[nofly]{size13.ly}
+
+@mudelafile[nofly]{size16.ly}
+
+@mudelafile[nofly]{size20.ly}
+
+@mudelafile[nofly]{size23.ly}
+
+@mudelafile[nofly]{size26.ly}
+
+
+@section Clefs and Time Signatures
+
+The transparent clef should not occupy any space and with style
+@code{fullSizeChanges}, the changing clef should be typeset in full
+size. For octaviated clefs, the ``8'' should appear closely above or
+below the clef respectively. The ``8'' is processed in a convoluted
+way, so this is fragile as well.
+
+@mudelafile{clefs.ly}
+
+@ignore
+@c the input file is too long and does not test for specific bugs
+By default, time signatures are written with two numbers. With style
+``C'', 4/4 and 2/2 are written with their corresponding symbols and
+with style ``old'', 2/2, 3/2, 2/4, 3/4, 4/4, 6/4, 9/4, 4/8, 6/8 and
+9/8 are typeset with symbols, all other signatures retain the default
+layout. The style ``1'', gives single number signatures for all
+signatures.
+%
+\mu delafile{time.fly}
+@end ignore
+
+@bye
@top
-
@unnumbered LilyPond -- The @uref{http://www.fsf.org/gnu/gnu-history.html,GNU Project} Music Typesetter
+
+@html
+<img src="Documentation/pictures/out-www/lelie-logo.png">
+@end html
+
@c something breaks on 3.12 f
-@c @center
-@quotation
-@mudela[fragment]
- \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 }
-@end mudela
-@end quotation
-@c @end center
-@c include BLURB?
LilyPond is a music typesetter. It produces beautiful sheet music
using a high level description file as input. LilyPond is part of
the GNU Project.
-@c include screenshot
+@c @center
+@quotation
+@mudela[fragment]
+ \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 }
+@end mudela
+@end quotation
+@c @end center
@unnumberedsec Sheet music
Grep -i for TODO, FIXME and ugh/ugr/urg.
.* TODO
+. * make this file understandable for 3rd parties.
. * use Rhythmic_head::position_i () for all Staff_referenced
. * .po -> .pot.
. * why need to run -C mf twice?
. * fix interstaff stuff
. * junk BLURB files.
. * setting indent to 0 with \shape fails
+. * here's no difference at all in output. When either is jacked up to 7.0,
+everything works and matches up; when either is set just a bit above the
+default 5.0 (5.4 is what I was hoping to use), stems miss note heads. So
+it's some sort of a numerical (truncation/roundoff) problem.
+John
+. * metre -> meter
+. * Fixed size staff heights;
. * ly2dvi : don't repeat opus if same.
. * breaks before mmrests are favored.
. * hara kiri _8 clef.
What's old about absolute to relative conversion? Could maybe use for
abc2ly, midi2ly?
+
.* Cleanups needed
. * \$ and $ identifier syntax in examples.
. * Junk ghost positioning objects eg, Script leans on Staffside
PACKAGE_NAME=LilyPond
MAJOR_VERSION=1
MINOR_VERSION=2
-PATCH_LEVEL=15
-MY_PATCH_LEVEL=jcn4
+PATCH_LEVEL=16
+MY_PATCH_LEVEL=
# use the above to send patches: MY_PATCH_LEVEL is always empty for a
# released version.
--- /dev/null
+\score{
+ \context PianoStaff <
+ \context Staff=one \notes\relative c'{
+ \stemup [c8 c \translator Staff=two \stemup c c]
+ [c c c c]
+ \translator Staff=one
+ \stemdown [c8 c \translator Staff=two \stemup c c]
+ r2
+ \stemdown [c8 c \translator Staff=one \stemdown c c]
+ r2
+ \translator Staff=two
+ \stemup [c8 c \translator Staff=one \stemdown c c]
+ r2
+ }
+ \context Staff=two \notes\relative c'{
+ \clef bass;
+ s1
+ s1
+ s1
+ s1
+ }
+ >
+ \paper{
+ \translator{
+ \PianoStaffContext
+ minVerticalAlign = 3.0*\staffheight;
+ maxVerticalAlign = 3.0*\staffheight;
+ }
+% linewidth=-1.;
+ }
+}
+
+\version "1.2.0";
+++ /dev/null
-\score{
- \context PianoStaff <
- \context Staff=one \notes\relative c'{
- \stemup [c8 c \translator Staff=two \stemup c c]
- [c c c c]
- \translator Staff=one
- \stemdown [c8 c \translator Staff=two \stemup c c]
- r2
- \stemdown [c8 c \translator Staff=one \stemdown c c]
- r2
- \translator Staff=two
- \stemup [c8 c \translator Staff=one \stemdown c c]
- r2
- }
- \context Staff=two \notes\relative c'{
- \clef bass;
- s1
- s1
- s1
- s1
- }
- >
- \paper{
- \translator{
- \PianoStaffContext
- minVerticalAlign = 3.0*\staffheight;
- maxVerticalAlign = 3.0*\staffheight;
- }
-% linewidth=-1.;
- }
-}
-
-\version "1.2.0";
+++ /dev/null
-#(begin (newline)(display "hello world")(newline))\score{
- \notes\relative c'{ c }
-}
-
--- /dev/null
+% test noStemExtend
+\context Staff <
+ \context Voice = "a" {
+ f2 f8 g a b
+ \property Voice.noStemExtend = 1
+ f2 f8 g a b
+ }
+ \context Voice = "b" {
+ c''2 c8 b a g
+ \property Voice.noStemExtend = 1
+ c2 c8 b a g
+ }
+>
--- /dev/null
+\score{
+ \context PianoStaff <
+ \context Staff=one \notes\relative c'{
+ \stemup c4( c \translator Staff=two c )c |
+ \translator Staff=one
+ \stemup c4( c \translator Staff=two c )c |
+ \stemup c4( c \translator Staff=one c )c |
+ \translator Staff=two
+ \stemup c4( c \translator Staff=one c )c |
+ \translator Staff=two
+ \stemup c4( \translator Staff=one c c )c |
+ r2
+ \translator Staff=two
+ \stemup c4( \translator Staff=one c
+ \break
+ c )c
+ r2
+% \stemdown c4( \translator Staff=two c c \translator Staff=one )c
+ \stemdown d4( \translator Staff=two c c \translator Staff=one )d
+ \translator Staff=two
+ \stemup c4( \translator Staff=one c c \translator Staff=two )c
+ r1
+ }
+ \context Staff=two \notes\relative c'{
+ \clef bass;
+ s1 s1 s1 s1 s1 s1 s1 s1 s1 s1
+ }
+ >
+ \paper{
+ \translator{
+ \PianoStaffContext
+ minVerticalAlign = 3.0*\staffheight;
+ maxVerticalAlign = 3.0*\staffheight;
+ }
+ %linewidth=100.\mm;
+ }
+}
+
+\version "1.2.0";
+++ /dev/null
-\score{
- \context PianoStaff <
- \context Staff=one \notes\relative c'{
- \stemup c4( c \translator Staff=two c )c |
- \translator Staff=one
- \stemup c4( c \translator Staff=two c )c |
- \stemup c4( c \translator Staff=one c )c |
- \translator Staff=two
- \stemup c4( c \translator Staff=one c )c |
- \translator Staff=two
- \stemup c4( \translator Staff=one c c )c |
- r2
- \translator Staff=two
- \stemup c4( \translator Staff=one c
- \break
- c )c
- r2
-% \stemdown c4( \translator Staff=two c c \translator Staff=one )c
- \stemdown d4( \translator Staff=two c c \translator Staff=one )d
- \translator Staff=two
- \stemup c4( \translator Staff=one c c \translator Staff=two )c
- r1
- }
- \context Staff=two \notes\relative c'{
- \clef bass;
- s1 s1 s1 s1 s1 s1 s1 s1 s1 s1
- }
- >
- \paper{
- \translator{
- \PianoStaffContext
- minVerticalAlign = 3.0*\staffheight;
- maxVerticalAlign = 3.0*\staffheight;
- }
- %linewidth=100.\mm;
- }
-}
-
-\version "1.2.0";
--- /dev/null
+%{
+Hmm, ik vraag me af of dit al helemaal koel is.
+
+ return abs (this_one.force_f_) + abs (prev.force_f_ - this_one.force_f_)
+ + break_penalties;
+
+Neem als voorbeeld iets dat lijkt op allemande: keuze tussen 2 of drie
+maten per regel.
+
+* 2 lange maten -> lelie kiest 2 /regel :beetje los
+* 3 korte -> lelie kiest 3 /regel :beetje krap
+* 2 korte, 1 lange -> 3/regel :krap
+* 1 korte, 2 lange -> 3/regel :erg krap
+* 3 lange -> 3/regel :urg krap
+
+als je naar beloningen kijkt, kan ik me goed voorstellen dat sprong
+van 'al wat krapper' naar los te groot wordt, en ze dus steeds krapper
+wordt, tot urg krap aan toe, want kracht lineair? Dat lijkt ook geval
+in allemande.
+
+Zie hoe eerst 10 en 9 mooi op 2maat/regel staan terwijl later tot 14
+toe 3/regel.
+
+Heb niet zomaar beter idee, nog.
+%}
+
+\score{
+ \notes\relative c'{
+ % 10
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 ces c ces
+
+ % 9
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 c ces c
+
+ % 1
+ c4 c c c
+ c4 c c c
+ c4 c c c
+
+ % 2
+ c4 c c c
+ c4 c c c
+ c4 c c8 c c c
+
+ % 3
+ c4 c c c
+ c4 c c c
+ c8 c c c c8 c c c
+
+ % 4
+ c4 c c c
+ c4 c c8 c c c
+ c8 c c c c8 c c c
+
+ % 5
+ c4 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+
+ % 6
+ c4 c c8 c c c
+ % c4 c c c8 c
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+
+ % 7
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+
+ % 8
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 c c ces
+
+ % 9
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 c ces c
+
+ % 10
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c c8 ces c ces
+
+ % 11
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c c ces8 c ces c
+
+ % 12
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c c ces c8 ces c ces
+
+ % 13
+ c8 c c c c8 c c c
+ c8 c c c c8 c c c
+ c8 c ces c ces8 c ces c
+
+ }
+ \paper {
+ indent=0.0\mm;
+ linewidth=90.0\mm;
+ }
+}
+
+
d b | c a | f g | c,2
}
-global = \notes {
- \time 2/4;
-}
tekst = \lyrics{
Al -- tijd is Kort -- jak -- je ziek, " "
\context Staff=i s1
\context Lyrics=top s1
\context GrandStaff <
- \context Staff=ii \repeat semi 2 < \global\melody >
- \context Staff=iii \repeat semi 2 < \global\accompany >
+ \context Staff=ii \repeat volta 2 <
+ \time 2/4;
+ \melody >
+ \context Staff=iii \repeat volta 2 <
+ \accompany >
>
\context Lyrics=bottom s1
% ugh, \repeat in \addlyrics dumps core
\addlyrics
- % \context Staff = i \repeat semi 2 <\global\melody>
- \context Staff = i <\global\melody>
+ \context Staff = i < \melody>
<
%\repeat fold 2 {}
%\alternative {
#include "note-head.hh"
#include "local-key-item.hh"
-#include <iostream.h>
Breathing_sign_engraver::Breathing_sign_engraver()
{
#include "dimensions.hh"
#include "direction.hh"
-#include <iostream.h>
Breathing_sign::Breathing_sign ()
{
SCM ly_append (SCM a, SCM b);
SCM ly_eval (SCM a);
SCM ly_func_o (char const* name);
-SCM ly_parse_scm (char const* s, int* n);
SCM ly_quote_scm (SCM s);
void ly_display_scm (SCM s);
String ly_scm2string (SCM s);
DECLARE_LY_SYMBOL(non_default);
DECLARE_LY_SYMBOL(non_rhythmic);
DECLARE_LY_SYMBOL(no_staff_support);
+DECLARE_LY_SYMBOL(no_stem_extend);
DECLARE_LY_SYMBOL(octave_dir);
DECLARE_LY_SYMBOL(origin);
DECLARE_LY_SYMBOL(output);
#ifndef MIDI_STREAM_HH
#define MIDI_STREAM_HH
-#include <iostream.h>
#include "string.hh"
/// Midi outputfile
Interpretation_context_handle handle_;
protected:
- bool playback_b_; // Should use SCMs
-
Music const * music_l_;
/// ugh. JUNKME
void set_translator (Translator_group*);
/** Get an iterator matching the type of MUS, and use TRANS to find
- an accompanying translation unit. Repeated music can be fully
- unfolded by setting PLAYING */
- static Music_iterator* static_get_iterator_p (Music const* mus, bool playing);
+ an accompanying translation unit
+ */
+ static Music_iterator* static_get_iterator_p (Music const* mus);
void init_translator (Music const *, Translator_group *);
Music_iterator();
#ifndef PAPER_STREAM_HH
#define PAPER_STREAM_HH
-#include <iostream.h>
#include "string.hh"
/** Paper output
source file of the LilyPond music typesetter
- (c) 1996--1999 Han-Wen Nienhuys <hanwen@cs.uu.nl>
- Jan Nieuwenhuizen <janneke@gnu.org>
+ (c) 1996,1997 Han-Wen Nienhuys <hanwen@cs.uu.nl>
*/
#include "my-lily-lexer.hh"
#include "array.hh"
#include "interval.hh"
-#include "lily-guile.hh"
#include "parser.hh"
#include "debug.hh"
#include "main.hh"
cerr << _ ("white expected") << endl;
exit (1);
}
-<INITIAL,chords,lyrics,notes># { //embedded scm
- //char const* s = YYText () + 1;
- char* s = (char*)YYText () + 1;
- int n = 0;
- if (!main_input_b_ && safe_global_b) {
- error (_ ("Can't evaluate Scheme in safe mode"));
- return SCM_EOL;
- }
- /*
- urg: replace 0 char with original value
- */
- *s = (char)yyinput ();
- yylval.scm = ly_parse_scm (s, &n);
-
- if (!n)
- unput (*s);
- else
- n--;
- /*
- urg, this
- yyin->seekg (n, ios::cur);
- doesn't work, is there no other way?
- */
- for (int i=0; i < n; i++)
- yyinput ();
- return SCM_T;
-}
<notes>{
{ALPHAWORD} {
return scan_bare_word (YYText ());
return gh_eval_str ((char*)c);
}
-
-/*
- Pass string to scm parser, evaluate one expression.
- Return result value and #chars read.
-
- Thanks to Gary Houston <ghouston@freewire.co.uk>
-
- Need guile-1.3.4 (>1.3 anyway) for ftell on str ports -- jcn
-*/
-SCM
-ly_parse_scm (char const* s, int* n)
-{
- SCM str = gh_str02scm ((char*)s);
- SCM port = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG,
- "scm_eval_0str");
- SCM from = scm_ftell (port);
-
- SCM form;
- SCM answer = SCM_UNSPECIFIED;
-
- /* Read expression from port */
- if (!SCM_EOF_OBJECT_P (form = scm_read (port)))
- answer = scm_eval_x (form);
-
- SCM to = scm_ftell (port);
- *n = gh_scm2int (to) - gh_scm2int (from);
-
- /* Don't close the port here; if we re-enter this function via a
- continuation, then the next time we enter it, we'll get an error.
- It's a string port anyway, so there's no advantage to closing it
- early. */
-
- return answer;
-}
-
/*
scm_m_quote doesn't use any env, but needs one for a good signature in GUILE.
*/
char * p = gh_scm2newstr (s , &len);
String r (p);
- // delete p;
+
free (p);
return r;
}
}
Music_iterator*
-Music_iterator::static_get_iterator_p (Music const *m, bool playing)
+Music_iterator::static_get_iterator_p (Music const *m)
{
Music_iterator * p =0;
p = new Music_wrapper_iterator;
else if (Repeated_music const * n = dynamic_cast<Repeated_music const *> (m))
{
- if (n->fold_b_ && !playing)
+ if (n->fold_b_)
p = new Folded_repeat_iterator;
else
p = new Unfolded_repeat_iterator;
}
else
assert (0);
-
- p->playback_b_ = playing;
+
p->music_l_ = m;
return p;
Music_iterator*
Music_iterator::get_iterator_p (Music const*m) const
{
- Music_iterator*p = static_get_iterator_p (m, playback_b_);
+ Music_iterator*p = static_get_iterator_p (m);
p->init_translator (m, report_to_l());
p->construct_children();
Music_iterator::Music_iterator()
{
- playback_b_ = false;
first_b_ = true;
}
#include "notename-table.hh"
#include "interval.hh"
#include "identifier.hh"
-#include "lily-guile.hh"
#include "parser.hh"
#include "keyword.hh"
#include "my-lily-lexer.hh"
{"repeat", REPEAT},
{"repetitions", REPETITIONS},
{"addlyrics", ADDLYRICS},
+ {"scm", SCM_T},
+ {"scmfile", SCMFILE},
{"score", SCORE},
{"script", SCRIPT},
{"shape", SHAPE},
#include "music-list.hh"
#include "musical-request.hh"
#include "command-request.hh"
-#include "lily-guile.hh"
#include "parser.hh"
#include "scope.hh"
#include "file-results.hh"
SCM_CDR(element_smob_list_) = gh_cons (elem_p->self_scm_,
SCM_CDR (element_smob_list_));
+ elem_p->set_elt_property (ly_symbol ("full-name"),
+ gh_str02scm((char*)elem_p->name()));
+
scm_unprotect_object (elem_p->self_scm_);
}
source file of the GNU LilyPond music typesetter
- (c) 1997--1999 Han-Wen Nienhuys <hanwen@cs.uu.nl>
+ (c) 1997 Han-Wen Nienhuys <hanwen@cs.uu.nl>
Jan Nieuwenhuizen <janneke@gnu.org>
*/
Real real;
Request * request;
Scalar *scalar;
- SCM scm;
String *string;
Tempo_req *tempo;
%token REPETITIONS
%token ADDLYRICS
%token SCM_T
+%token SCMFILE
%token SCORE
%token SCRIPT
%token SHAPE
%token <real> REAL
%token <string> DURATION RESTNAME
%token <string> STRING
-%token <scm> SCM_T
%token <i> UNSIGNED
%type <duration> duration_length
%type <scalar> scalar
-%type <scm> embedded_scm
%type <music> Music Sequential_music Simultaneous_music Music_sequence
%type <music> relative_music re_rhythmed_music
%type <music> property_def translator_change
Midi_def_identifier ($1, MIDI_IDENTIFIER);
THIS->lexer_p_->set_identifier ("$defaultmidi", id)
}
- | embedded_scm {
- // junk value
- }
+ | embedded_scm {
+ }
;
embedded_scm:
- SCM_T
- ;
+ SCMFILE STRING semicolon {
+ read_lily_scm_file (*$2);
+ delete $2;
+ }
+ | SCM_T STRING semicolon {
+ if (THIS->lexer_p_->main_input_b_ && safe_global_b)
+ error (_("Can't evaluate Scheme in safe mode"));
+ gh_eval_str ($2->ch_l ());
+ delete $2;
+ };
chordmodifiers_block:
#include "lily-guile.hh"
#include "main.hh"
-#ifdef LYPROT
-#define PROTECT ly_protect_scm
-#define UNPROTECT ly_unprotect_scm
-#else
-#define PROTECT scm_protect_object
-#define UNPROTECT scm_unprotect_object
-#endif
-
Protected_scm::Protected_scm ()
{
object_ = 0;
Protected_scm::Protected_scm (SCM s)
{
- object_ = s ? PROTECT (s): 0;
+ object_ = s ? scm_protect_object (s): 0;
}
Protected_scm::Protected_scm (Protected_scm const &s)
{
- object_ = s.object_ ? PROTECT (s.object_) : 0;
+ object_ = s.object_ ? scm_protect_object (s.object_) : 0;
}
Protected_scm &
if (object_ == s)
return *this;
if (object_)
- UNPROTECT(object_);
+ scm_unprotect_object(object_);
- object_ = s ? PROTECT (s): 0;
+ object_ = s ? scm_protect_object (s): 0;
return *this;
}
{
if (object_)
{
- UNPROTECT (object_);
- object_ =0L; // be nice to conservative GC
+ scm_unprotect_object (object_);
}
}
Score_element::~Score_element()
{
- delete output_p_;
+ assert (!output_p_);
assert (status_i_ >=0);
status_i_ = -1;
}
{
if (self_scm_ != SCM_EOL)
return self_scm_;
-
+
+ /*
+ This is local. We don't assign to self_scm_ directly, to assure
+ that S isn't GC-ed from under us.
+ */
SCM s;
SCM_NEWCELL(s);
void * mp = (void*) SCM_CDR(ses);
Score_element * s = (Score_element*) mp;
- assert (s->self_scm_ == ses);
+ if (s->self_scm_ != ses)
+ {
+ programming_error ("Score_element::mark_smob(): self_scm_ != ses; this will probably crash");
+ cout << "ses == " << ses << endl;
+ cout << "name == " << s->name() << endl;
+ gh_display (s->element_property_alist_);
+ gh_newline ();
+ }
return s->element_property_alist_;
}
trans_p->last_mom_ = music_p_->length_mom ();
- bool playing = odef_l->scope_p_->elem_b ("unfold_all");
- Music_iterator * iter = Music_iterator::static_get_iterator_p (music_p_, playing);
+ Music_iterator * iter = Music_iterator::static_get_iterator_p (music_p_);
iter->init_translator(music_p_, trans_p);
iter->construct_children();
Cons<Music> *i = (sim->music_p_list_p_) ? sim->music_p_list_p_->head_ : 0;
for (; i; i = i->next_, j++)
{
- Music_iterator * mi = static_get_iterator_p (i->car_, playback_b_);
+ Music_iterator * mi = static_get_iterator_p (i->car_);
/* if separate_contexts_b_ is set, create a new context with the
number number as name */
}
while (flip (&d) != LEFT);
- bool cross_count = cross_staff_count ();
+ int cross_count = cross_staff_count ();
bool interstaff_b = (0 < cross_count) && (cross_count < encompass_arr_.size ());
Drul_array<Offset> info_drul;
- Interval interstaff_interval;
+ Drul_array<Real> interstaff_interval;
do
{
}
while (flip (&d) != LEFT);
- Real interstaff_f = interstaff_interval.length ();
+ Real interstaff_f = interstaff_interval[RIGHT] - interstaff_interval[LEFT];
if (fix_broken_b)
{
stem_p_->set_elt_property (style_scm_sym, ly_ch_C_to_scm (prop.ch_C()));
}
+ prop = get_property ("noStemExtend", 0);
+ if (prop.to_bool ())
+ {
+ stem_p_->set_elt_property (no_stem_extend_scm_sym, gh_int2scm (1));
+ }
+
typeset_element(stem_p_);
stem_p_ = 0;
}
SCM bd = stem_l_->remove_elt_property (beam_dir_scm_sym);
beam_dir_ = gh_scm2int (SCM_CDR(bd));
- interstaff_f_ = 0;
Paper_def* paper_l = stem_l_->paper_l ();
Real internote_f = stem_l_->staff_line_leading_f ()/2;
idealy_f_ *= beam_dir_;
bool grace_b = stem_l_->get_elt_property (grace_scm_sym) != SCM_BOOL_F;
+ bool no_extend_b = stem_l_->get_elt_property (no_stem_extend_scm_sym)
+ != SCM_BOOL_F;
int stem_max = (int)rint(paper_l->get_var ("stem_max"));
String type_str = grace_b ? "grace_" : "";
than middle staffline, just as normal stems.
*/
- if (!grace_b)
+ if (!grace_b && !no_extend_b)
{
//highest beam of (UP) beam must never be lower than middle staffline
miny_f_ = miny_f_ >? 0;
// interstaff beam
Beam* beam_l = stem_l_->beam_l_;
- Real is = calc_interstaff_dist (stem_l_, beam_l);
- idealy_f_ += is* beam_dir_;
- miny_f_ += is * beam_dir_;
- maxy_f_ += is * beam_dir_;
+ interstaff_f_ = calc_interstaff_dist (stem_l_, beam_l) / internote_f;
+ idealy_f_ += interstaff_f_* beam_dir_;
+ miny_f_ += interstaff_f_ * beam_dir_;
+ maxy_f_ += interstaff_f_ * beam_dir_;
}
set_stemend ((dir_ > 0) ? head_positions()[BIGGER] + length_f:
head_positions()[SMALLER] - length_f);
- if (!grace_b && (dir_ * stem_end_f () < 0))
+ bool no_extend_b = get_elt_property (no_stem_extend_scm_sym) != SCM_BOOL_F;
+ if (!grace_b && !no_extend_b && (dir_ * stem_end_f () < 0))
set_stemend (0);
}
{
done_mom_ += mus->repeat_body_p_->length_mom ();
- if (full_unfold_b_)
+ if (!mus->volta_fold_b_)
done_count_ ++;
if (alternative_cons_l_)
current_iter_p_ = get_iterator_p (alternative_cons_l_->car_);
do_main_b_ = false;
}
- else if (done_count_ < mus->repeats_i_ && full_unfold_b_)
+ else if (done_count_ < mus->repeats_i_ && !mus->volta_fold_b_)
{
current_iter_p_ = get_iterator_p (mus->repeat_body_p_);
do_main_b_ = true;
{
done_mom_ += alternative_cons_l_->car_->length_mom ();
- if (!full_unfold_b_ ||
+ if (mus->volta_fold_b_ ||
mus->repeats_i_ - done_count_ < alternative_count_i_)
alternative_cons_l_ = alternative_cons_l_->next_;
/*
we've done the main body as well, but didn't go over the other
increment. */
- if (full_unfold_b_)
+ if (mus->volta_fold_b_)
done_count_ ++;
}
if (done_count_ < mus->repeats_i_ && alternative_cons_l_)
{
- if (!full_unfold_b_)
+ if (mus->volta_fold_b_)
current_iter_p_ = get_iterator_p (alternative_cons_l_->car_);
else
{
Unfolded_repeat_iterator::construct_children ()
{
Repeated_music const* mus =dynamic_cast<Repeated_music const*> (music_l_);
- full_unfold_b_ = playback_b_ || (!mus->volta_fold_b_);
-
alternative_cons_l_ = (mus->alternatives_p_)
? mus->alternatives_p_->music_p_list_p_->head_
: 0;
% 16' = S
%
-#(primitive-load-path "accordion-script.scm")
+\scmfile "accordion-script.scm";
accDiscant = \script "accDiscant"
accDiscantF = \script "accDiscantF"
% chop off this much when next to pp / ff sign.
crescendo_shorten = 4.0 * \interline;
crescendo_thickness = \stafflinethickness;
-crescendo_height = 1.5 * \interline;
+crescendo_height = 0.666 * \interline;
% in internote.
restcollision_minimum_dist = 3.0;
-#(primitive-load-path "script.scm")
+\scmfile "script.scm";
"dash-hat" = "marcato"
"dash-plus" = "stopped"
upprall = \script "upprall"
downprall = \script "downprall"
segno = \script "segno"
-coda = \script "coda"
+coda = \script "coda"
\ No newline at end of file
%description documentation
@BLURB@
-The documentation package is rather big, due to the many pictures and
-different documentation formats. It is really a rip-off from the
-LilyPond website. If you have direct internet access, you may always
-read the documentation documentation there: http://www.lilypond.org.
+The documentation of LilyPond, both in HTML and PostScript.
%prep
%setup
Begin3
Title: LilyPond
-Version: 1.2.15
-Entered-date: 18OCT99
+Version: 1.2.16
+Entered-date: 21OCT99
Description:
Keywords: music notation typesetting midi fonts engraving
Author: hanwen@cs.uu.nl (Han-Wen Nienhuys)
janneke@gnu.org (Jan Nieuwenhuizen)
Maintained-by: hanwen@stack.nl (Han-Wen Nienhuys)
Primary-site: sunsite.unc.edu /pub/Linux/apps/sound/convert
- 1000k lilypond-1.2.15.tar.gz
+ 1000k lilypond-1.2.16.tar.gz
Original-site: ftp.cs.uu.nl /pub/GNU/LilyPond/development/
- 1000k lilypond-1.2.15.tar.gz
+ 1000k lilypond-1.2.16.tar.gz
Copying-policy: GPL
End
Name: lilypond
-Version: 1.2.15
+Version: 1.2.16
Release: 1
Copyright: GPL
Group: Applications/Publishing
-Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.15.tar.gz
+Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.16.tar.gz
Summary: A program for printing sheet music.
URL: http://www.cs.uu.nl/~hanwen/lilypond
Packager: Han-Wen Nienhuys <hanwen@cs.uu.nl>
%description documentation
-The documentation package is rather big, due to the many pictures and
-different documentation formats. It is really a rip-off from the
-LilyPond website. If you have direct internet access, you may always
-read the documentation documentation there: http://www.lilypond.org.
+The documentation of LilyPond, both in HTML and PostScript.
%prep
%setup
-
\version "1.2.0";
\include "allemande-urtext.ly";
;(debug-enable 'backtrace)
;;; library funtions
+
+; :use-module (ice-9 regex))
+
(define
(xnumbers->string l)
(string-append
system ('lilypond %s %s' % (lilyopts, texfiles))
for e in eps:
- cmd = r"""tex %s; dvips -E -o %s %s""" % \
+ cmd = r"""tex '\nonstopmode \input %s'; dvips -E -o %s %s""" % \
(e, e + '.eps', e)
system (cmd)
' -T, --dir-to=TO diff to directory TO\n'
)
+def cleanup ():
+ global from_diff, to_diff, prev_cwd
+ os.chdir ('/tmp/package-diff')
+ sys.stderr.write ('Cleaning ... ')
+ os.system ('rm -fr %s %s' % (from_diff, to_diff))
+ sys.stderr.write ('\n')
+ os.chdir (prev_cwd)
+
def untar (fn):
# os.system ('pwd');
- sys.stderr.write ('untarring ' + fn + '\n')
+ try:
+ open (fn)
+ except:
+ sys.stderr.write ("Can't find tarball: %s\n" % fn)
+ cleanup ()
+ sys.exit (1)
+ sys.stderr.write ("Untarring: %s\n" % fn)
os.system ('gzip --quiet -dc ' + fn + '| tar xf - ')
sys.stderr.flush ()
files = []
for d in dirnames:
- for p in pats:
- files = files + find.find (p, d)
+ try:
+ for p in pats:
+ files = files + find.find (p, d)
+ except:
+ sys.stderr.write ("Can't find dir: %s\n" % d)
+ cleanup ()
+ sys.exit (1)
dirs = map (lambda d: find.find ('out', d), dirnames)
dirs = reduce (lambda x,y: x + y, dirs)
os.chdir (to_diff)
makediff (from_diff, to_diff, patch_name)
-os.chdir ('/tmp/package-diff')
-sys.stderr.write ('cleaning ... ')
-os.system ('rm -fr %s %s' % (from_diff, to_diff))
-sys.stderr.write ('\n')
-os.chdir (prev_cwd)
-
+cleanup ()
pass
os.link(orig, os.path.join (package.release_dir, tarball))
+# urg: howto check exit code?
os.system(sys.executable + ' ' + package.topdir + '/stepmake/bin/package-diff.py --package=' + topdir)
diffname = pn + '.diff.gz'
diffname = os.path.join (outdir, diffname)
-os.rename(diffname, rel_pn)
+try:
+ os.rename(diffname, rel_pn)
+except:
+ sys.stderr.write ("Can't find diff: %s\n" % diffname)
+ sys.exit (1)
os.link(rel_pn, diffname)
rm -f `find . -name \*.html~ -print`
$(footify-all-command)
find `find Documentation -type d -name 'out-www'` -not -name '*dvi' -not -name '*ly' -not -name '*tex' -not -name '*.ps' -not -name 'out-www' > wwwlist
- tar cfz $(outdir)/htmldoc.tar.gz `cat wwwlist` `ls *.png out-www/$(distname).diff.gz $(ERRORLOG)` index.html
+ tar cfz $(outdir)/htmldoc.tar.gz `cat wwwlist` `ls *.png $(ERRORLOG)` index.html
localclean:
rm -f wwwlist
\newcommand*{\instrument}[1]{\def\theinstrument{#1}}
\newcommand*{\opus}[1]{\def\theopus{#1}}
\newcommand*{\piece}[1]{\def\thepiece{#1}}
-\newcommand*{\metre}[1]{\def\themetre{#1}}
+\newcommand*{\meter}[1]{\def\themeter{#1}}
\newcommand*{\poet}[1]{\def\thepoet{#1}}
%
\newcommand*{\mudelatitle}[1]{\def\thetitle{#1}}
\newcommand*{\mudelainstrument}[1]{\def\theinstrument{#1}}
\newcommand*{\mudelaopus}[1]{\def\theopus{#1}}
\newcommand*{\mudelapiece}[1]{\def\thepiece{#1}}
-\newcommand*{\mudelametre}[1]{\def\themetre{#1}}
-\newcommand*{\mudelameter}[1]{\def\themetre{#1}}
+\newcommand*{\mudelametre}[1]{\def\themeter{#1}}
+\newcommand*{\mudelameter}[1]{\def\themeter{#1}}
\newcommand*{\mudelapoet}[1]{\def\thepoet{#1}}
%
%
\edef\saveparskip{\parskip}\parskip-5mm
\begin{minipage}[t]{0.45\textwidth}
\ifx\mudelanull\thepoet\else{\thepoet}\\ \fi
- \ifx\mudelanull\themetre\else{\themetre}\\ \fi
+ \ifx\mudelanull\themeter\else{\themeter}\\ \fi
\end{minipage}\hspace*{\fill}
\begin{minipage}[t]{0.45\textwidth}
\begin{flushright}
projects / lilypond.git / commitdiff