<b>Mailing Lists</b>
</td></tr>
<tr><td><font size=-1>
+ <a href="@TOP@Documentation/out-www/index.html#mailing-lists">About the lists</a><br>
<a href="http://mail.gnu.org/mailman/listinfo/gnu-music-discuss/">Discussion</a><br>
<a href="http://mail.gnu.org/mailman/listinfo/help-gnu-music">Help</a><br>
<a href="http://mail.gnu.org/mailman/listinfo/bug-gnu-music/">Bugs</a><br>
@itemize @bullet
+@item @uref{http://mail.gnu.org/mailman/listinfo/gnu-music-discuss,gnu-music-discuss@@gnu.org}
+This list is for discussions concerning LilyPond.
+
+Searchable archives are available from
+@uref{http://www.mail-archive.com/gnu-music-discuss@@gnu.org}.
+
@item @uref{http://mail.gnu.org/mailman/listinfo/info-gnu-music,info-gnu-music@@gnu.org}
is a low-volume list for information on the GNU Music project.
This list is moderated; ask
@email{drl@@gnu.org, David R. Linn} or
@email{hanwen@@cs.uu.nl, Han-Wen} to send announcements for this list.
+
+Searchable archives are available from
+@uref{http://www.mail-archive.com/info-gnu-music@@gnu.org}.
+
@item @uref{http://mail.gnu.org/mailman/listinfo/help-gnu-music,help-gnu-music@@gnu.org}
For help with using LilyPond.
+
+Searchable archives are available from
+@uref{http://www.mail-archive.com/help-gnu-music@@gnu.org}.
+
@item @uref{http://mail.gnu.org/mailman/listinfo/bug-gnu-music,bug-gnu-music@@gnu.org}
If you have bugreports, you should send them to this list.
-
Please include in your bugreport the version of LilyPond that
you experience the problem with, a description of your system and sample
input to reproduce the problem. Do not send output files over the list,
they tend to be very big and don't help with describing the problem.
-@item @uref{http://mail.gnu.org/mailman/listinfo/gnu-music-discuss,gnu-music-discuss@@gnu.org}
- For discussions concerning LilyPond.
+Searchable archives are available from
+@uref{http://www.mail-archive.com/bug-gnu-music@@gnu.org}.
+
@end itemize
These pages were entirely created from a @strong{development snapshot}
@lilypondfile[printfilename]{tie-accidental.ly}
-
@lilypondfile[printfilename]{tup.ly}
+@lilypondfile[printfilename]{tuplet-beam.ly}
+
+@lilypondfile[printfilename]{tuplet-staffline-collision.ly}
+
@section Property details
@subsection Red Hat Linux
Red Hat 7.0 i386 RPMS are available from
-@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/RedHat/}.
+@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/}.
You can also compile them yourself. A spec file is in
@file{make/out/redhat.spec}. This file is distributed along with the
sources. You can make the rpm by issuing
@example
- rpm -tb lilypond-x.y.z.tar.gz
+ tar xfz lilypond-x.y.z.tar.gz
+ rpm -bb lilypond-x.y.z/make/out/redhat.spec
rpm -i /usr/src/redhat/RPMS/i386/lilypond-x.y.z
-
+
@end example
For running on a Red Hat system you need these packages: guile, tetex,
guile-devel, flex, bison, texinfo, tetex-devel, groff,
libgr-progs.
+
+@b{Warning}
+
+There appears to be a problem with the Xdvi shipped with RedHat
+7.1. Symptoms: Xdvi responds very sluggishly or hangs while viewing
+lilypond output. The cause for this problem is unknown; you are advised
+to recompile Xdvi from source.
+
+@subsection LinuxPPC
+
+
+Some LinuxPPC RPMS should available from
+@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/}.
+
+A LinuxPPC RPM can be made using the @file{redhat.spec} file.
+
@subsection SuSE
-You can also compile them yourself. A spec file is in
-@file{make/out/suse.spec}. This file is distributed along with the
-sources.
+Some SUSE RPMS should available from
+@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/}.
+
+You can also compile a RPM for SUSE yourself. A spec file is in
+@file{make/out/suse.spec}, see the instructions for building the RedHat
+RPM.
You must have the following packages: guile tcsh tetex te_latex te_kpath
te_mpost libpng python gpp libgpp gettext autoconf netpbm libnetpb
@subsection Slackware
+No precompiled packages for Slackware are available.
+
Problems have been reported with Slackware 7.0; apparently, it ships
with a faulty compiler. Do not compile LilyPond with -O2 on this
platform.
@subsection Mandrake
-[TODO]
+Some binaries are available at rpmfind.net. Refer to
+@uref{ftp://ftp.rpmfind.net/linux/Mandrake-devel/cooker/contrib/RPMS/}.
+
@subsection Debian GNU/Linux
@unnumberedsec What is LilyPond? What can it do for you?
-LilyPond prints music notation. It produces beautiful sheet music from
+LilyPond prints beautiful sheet music. It produces music notation from
a description file. It excels at typesetting classical music, but you
can also print pop-songs.
@lilypond[13pt,eps]
\property Score.barNonAuto = ##t
-\property Lyrics.LyricText \set #'font-style = #'large
-\property Voice.TextScript \set #'font-style = #'large
+\property Score.LyricText \set #'font-style = #'large
+\property Score.TextScript \set #'font-style = #'large
\addlyrics
-\notes\relative c' {
+ \context Staff \notes\relative c' {
c1 d
\property Voice.TextScript \set #'padding = #-10
e^"~~ S" f g a
I: coda (uncinata), bandiera, F: crochet, D: Fahne, F@"ahnchen, NL: vlaggetje,
DK: fane, S: flagga, N: .
-Ornament at the end of the stem of a note used for notes with values less than
-a quarter note. The number of flags determines the @w{@ar{}@strong{note value}}.
+Ornament at the end of the stem of a note used for notes with values
+less than a quarter note. The number of flags determines the
+@w{@ar{}@strong{note value}}.
@lilypond[13pt,eps]
@node First steps
@section First steps
-Let's try to explain this example:
-
-The basics of any piece of music are notes.Notes are entered
-with letters @code{a} to @code{g} followed by a
+The basics of any piece of music are notes. Notes are entered
+with letters @code{a} to @code{g}, followed by a
number that represents the duration: a @code{2} is a half note, a
-@code{4} is a quarter note. A period is used for augmentation dots, so
+@code{4} is a quarter note. A period adds a dot to the note, so
entering @code{2.} gives a dotted half note.
@example
c2 e4 g2.
@lilypond[fragment]
\time 3/4
\clef bass
- s2._" "
+ s2_" "
@end lilypond
The commands together with the notes are combined to form a snippet of
This snippet is ready to be printed. This is done by combining the music
with a printing command. The printing command is the so-called
-@code{\paper} block. The music and paper block are combined by
-enclosing them in @code{\score}.
+@code{\paper} block. You will see later that the \paper block is
+necessary to customize all kinds of printing specifics. The music and
+paper block are combined by enclosing them in @code{\score}.
@lilypond[verbatim]
\score {
don't have to be marked explicitly. You just enter the pitch, and
LilyPond determines wether or not to print an accidental.
-Managing larger pieces.
-
If you look at the last piece, it is already apparent that entering
octaves using quotes is not very convenient. A score written in high
register will be encoded using lots quotes. This makes the input file
are used to mark large jumps in the melody. Without any quotes or
commas, the interval between a note and its predecessor is assumed to be
a fourth or less. Quotes and commas add octaves in up and down
-direction. Relative octaves are introduced by @code{\relative} followed
-by a starting pitch
+direction.
@lilypond[fragment,verbatim]
\relative c'' { c4 d4 b4 e4 a,4 f'4 g,4 a'4 }
@end lilypond
+You can enter a piece in relative mode, by putting @code{\relative} in
+front. You also have to enter a starting pitch, in this case @code{c''}.
+
Slurs (not to be confused with ties) are entered with parentheses. You
mark the starting note and ending note with a @code{(} and a
@code{)} respectively.
-@lilypond[fragment,relative 2, verbatim]
+@lilypond[fragment,relative 1, verbatim]
c8( cis d ) e
@end lilypond
If you need two slurs at the same time (one for articulation, one for
-phrasing), you can also make phrasing slurs with @code{\(} and
+phrasing), you can also make a phrasing slur with @code{\(} and
@code{\)}.
@c lousy example
\context Staff = staffB { \clef bass c }
>
@end lilypond
-Here, @code{staffA} and @code{staffB} are names that you give to the
-staff. For now, it doesn't matter what names you give, as long as they
-are different.
+Here, @code{staffA} and @code{staffB} are names that you give them to
+the staff. For now, it doesn't matter what names you give them, as long
+as they are different.
We can typeset a melody with two staffs now:
(the top staff), but is printed on both. LilyPond knows that the time
signature should be the same for all staffs.
-[TODO add some more here
+Dynamic signs are made by adding the markings after the note
+@lilypond[verbatim,relative 1]
+c-\ff c-\mf
+@end lilypond
+
+Crescendi are started with the commands @code{\<} and @code{\>}. The
+command @code{\!} finishes a crescendo on the following.
+@lilypond[verbatim,relative 1]
+c2 \< \! c2-\ff \> c2 \! c2
+@end lilypond
+
+Chords can be made by surrounding notes with @code{<} and @code{>}:
+@lilypond[relative 0, fragment,verbatim]
+ r4 <c e g> <c f a>
+@end lilypond
+
+@c te diepzinnig?
+
+In general, @code{ < @var{stuff} > } is used when @var{stuff} all
+happens at the same time, like in chords, or (like in the two-staff
+example above) in a bunch of stacked staffs.
+
+Of course, you can combine beams and ties with chords:
+@lilypond[relative 0, fragment,verbatim]
+ r4 [<c8 e g> <c8 f a>] ~ <c8 f a>
+@end lilypond
+
+When you want to combine chords with slurs and dynamics, an annoying
+technical detail crops up: you have type these commands next to the
+notes, which means that they have to be inside the @code{< >}:
+
+@lilypond[relative 0, fragment,verbatim]
+ r4 <c8 e g \> ( > <c e g> <c e g> < ) \! c8 f a>
+@end lilypond
+
+A nasty technical detail also crops up when you start a score with a
+chord:
+@lilypond[verbatim,singleline]
+\score { \notes <c'1 e'1> }
+@end lilypond
+The program can not guess that you want the notes on only one staff. To
+force the chord on a staff, add @code{\context Staff} like this:
+@lilypond[verbatim,singleline]
+\score { \notes \context Staff <c'1 e'1> }
+@end lilypond
-* \header
-* dynamics , articulation
-* <chords>
+@ignore
+[TODO add some more here
+
+* lyrics, chords (?)
+
+* \header
* identifiers?
]
+@end ignore
-This is the end of the simple tutorial. What follows is also a manual in
-tutorial-style, but it is much more in-depth, and alas more
-intimidating. You should read it if you want to know about the more
-advanced features of lilypond, such as producing orchestral scores and
-parts, fine tuning output, writing polyphonic music, etc.
+This is the end of the simple tutorial. You know the basic ingredients
+of a music file, so this is the right moment to try your at hand at
+doing it yourself: try to type some simple examples, and experiment a
+little.
+
+When you're comfortable with the basics, then you might want to read the
+rest of this chapter. It also a manual in tutorial-style, but it is much
+more in-depth. It will also be very intimidating if you're not familiar
+with the basics. It deals with some of the more advanced features of
+lilypond. Topics include lyrics, chords, orchestral scores and parts,
+fine tuning output, polyphonic music, and integrating text and music.
subdirectory @file{input/tutorial/}@footnote{When we refer to filenames,
they are relative to the top directory of the source package. }
-
To demonstrate what LilyPond input looks like, we start off with a
full-fledged, yet simple example. It is a convoluted version
of the famous minuet in J. S. Bach's @emph{Klavierb@"uchlein}. The file
% all text after a percent sign is a comment
% and is ignored by Lilypond
@end example
-The percent sign, @code{%}, introduces a line comment. You can also
-comment out a block of several lines, by enclosing them in
-@code{%@{} and @code{%@}}.
+Percent signs introduce comments: everything after a percent sign is
+ignored. You can use this to write down mental notes to yourself. You
+can also make longer comments by enclosing text in @code{%@{} and
+@code{%@}}.
@cindex comment
@cindex block comment
@cindex line comment
@cindex @code{\include}
@cindex point, printer's
@cindex staff size setting
-By default, LilyPond will typeset the music in a size such that each
-staff is 20 point@footnote{A point is the standard measure of length for
-printing; one point is 1/72.27 inch.} high. We want smaller
-output (16 point staff height), so we must import the settings for that
-size, which is done here.
+By default, LilyPond will typeset the music in a size such that each
+staff is 20 point (0.7 cm, or 0.27 inch) high. We want smaller output
+(16 point staff height), so we must import the settings for that size,
+which is done here.
@separate
@example
@end example
@cindex augmentation dot
-@cindex dot
-A period adds an augmentation dot to the note.
+@cindex dotted note
+A period adds a dot to the note.
@separate
@example
@example
\version "1.3.124"
-\header @{ title = "Two miniatures" @}
+\header @{
+ title = "Two miniatures"
+ tagline = "small is beautiful"
+@}
#(set! point-and-click line-column-location)
@end lilypond
This file is produced by ly2dvi in a few stages, with the help of text
-formatting tools. LilyPond produces two output files, @file{miniatures.tex}
-and @file{miniatures-1.tex}. They both look like this:
-
-@example
- ...
- \placebox@{-5 \outputscale @}%
- @{ 8.7229 \outputscale @}%
- @{\magfontWXGEomMMBo\char90 @}%
-
- \placebox@{-4 \outputscale @}%
- @{ 81.0647 \outputscale @}%
- ...
-@end example
-
-@file{ly2dvi} looks at what output LilyPond produces, and generates a
-file called @file{ly2dvi.out.tex}. This file contains formatting
-instructions for the title and page layout. A fragment might look like
-
-@example
-
- \def\lilypondopus@{Opus 1.@}
- \def\lilypondpiece@{Up@}
- \def\mustmakelilypondtitle@{@}
- \input miniatures.tex
- \def\lilypondtitle@{Two miniatures@}
-
-@end example
-
-@file{ly2dvi} runs it through LaTeX. LaTeX is a text-formatting system
-built on top of @TeX{}. It's very popular in the academic world. If LaTeX
-is successful, this will produce a @file{.dvi} file, containing both the
-titling and the actual music. @code{ly2dvi} completes its task by
-deleting the two temporary files, leaving only @file{miniatures.dvi}.
+formatting tools. LilyPond produces two output files,
+@file{miniatures.tex} and @file{miniatures-1.tex}. Both files contain
+only graphical music notation. @file{ly2dvi} looks at what output
+LilyPond produces, and adds page layout and titling to those files. The
+result is a DVI file called @file{miniatures.dvi}.
Next, now we'll look at the example line by line to explain new things.
@separate
@example
- \header @{ title = "Two miniatures" @}
+ \header @{
+ title = "Two miniatures" @}
@end example
This sets the titling information for the entire file.
-
+@separate
+@example
+ tagline = "small is beautiful"
+@end example
+A signature line is printed at the bottom of the last page.
+ This signature is produced from the @code{tagline} field of
+@code{\header}. Many people find the default "Lily was here,
+@var{version number}" too droll. If that is the case, assign
+something else to @code{tagline}, as shown above.
@separate
@example
#(set! point-and-click line-column-location)
large files: if you're digitizing existing music, you have to
synchronize the .ly file, the sheet music on your lap and the sheet
music on the screen. The point-and-click mechanism makes it easy to
-find the origin of an error in the .ly file: when you view the file with
+find the origin of an error in the LY file: when you view the file with
Xdvi and click on a note, your editor will jump to the spot where that
note was entered. For more information, see @ref{Point and click}.
When you're copying music from existing sheet music, relative octaves
are probably the easiest to use: it's less typing work and errors are
-easily spotted. However, if you write LilyPond input, either by hand
-(ie. composing) or by computer, absolute octaves are probably less work.
+easily spotted. However, if you write LilyPond input directly, either by
+hand (i.e. composing) or by computer, absolute octaves are easier to use.
@separate
That's all folks. From here, you can either try fiddling with input
files, or you can read the reference manual. You can find more example
files in @file{input} and @file{input/test}. You can also look at some
-real music. Have a look at the @uref{Mutopia project,
-http://www.mutopiaproject.org}.
+real music. The website @uref{http://www.mutopiaproject.org} has many
+examples of real music typeset by LilyPond.
--- /dev/null
+
+\header {
+texidoc = "Stems are extended if flags and dots collide."
+}
+
+\score{
+ \notes\relative c'{ f8. g f16. g f32. g}
+}
+
--- /dev/null
+\header {
+
+texidoc = "In combination with a beam, the bracket of the tuplet
+bracket is removed. This only happens if there is one beam, as long as
+the bracket."
+
+}
+
+\score { \notes \context Voice\relative c'' {
+\times 2/3 { r [c8 c8] }
+\times 2/3 { [c8 c c] }
+\times 2/3 { [c16 c16] [c8 c8] }
+}}
--- /dev/null
+\header {
+
+texidoc = "Horizontal tuplet brackets are shifted vertically
+to avoid staff line collisions."
+
+}
+
+\score { \notes \context Voice\relative c'' {
+\times 2/3 { b'4 b b }
+\times 2/3 { f4 f f }
+\times 2/3 { g4 g g }
+\times 2/3 { a4 a a }
+}}
\version "1.3.138"
-\header { title = "Two miniatures" }
+\header {
+ title = "Two miniatures"
+ tagline = "Small is beatiful"
+}
#(set! point-and-click line-column-location)
/*
TODO: make callback of this.
+
+ TODO:
+
+ note-width is hardcoded, making it difficult to handle all note
+ heads sanely. We should really look at the widths of the colliding
+ columns, and have a separate setting for "align stems".
+
+
*/
void
Collision::do_shifts (Grob* me)
SCM hand (forced_shift (me));
Link_array<Grob> done;
-
+
+
Real wid
= gh_scm2double (me->get_grob_property ("note-width"));
&& (get_direction (me) != get_default_dir (me)))
length_f -= shorten_f;
+ Interval hp = head_positions (me);
+ Real st = hp[dir] + dir * length_f;
+
+ /*
+ Make a little room if we have a flag and there is a dot.
+
+ TODO:
+
+ maybe we should consider moving the dot to the right?
+ */
+
+ if (!beam_l (me)
+ && flag_i (me))
+ {
+ Grob * closest_to_flag = extremal_heads (me)[dir];
+ Grob * dots = closest_to_flag
+ ? Rhythmic_head::dots_l (closest_to_flag ) : 0;
- Real st = head_positions (me)[dir] + dir * length_f;
+ if (dots)
+ {
+ Real dp = Staff_symbol_referencer::position_f (dots);
+ Real flagy = flag (me).extent (Y_AXIS)[-dir] * 2; // should divide by staffspace
+
+ if (dir * (st + flagy - dp) < 0)
+ st += (fabs (st + flagy - dp) + 1.0) *dir;
+ }
+ }
bool no_extend_b = to_boolean (me->get_grob_property ("no-stem-extend"));
if (!grace_b && !no_extend_b && dir * st < 0) // junkme?
y_attach = head_height.linear_combination (y_attach);
stem_y[Direction (-d)] += d * 2*y_attach;
}
-
if (!invisible_b (me))
{
(c) 1997--2001 Jan Nieuwenhuizen <janneke@gnu.org>
*/
+#include <math.h>
#include "beam.hh"
#include "box.hh"
#include "group-interface.hh"
#include "directional-element-interface.hh"
#include "spanner.hh"
+#include "staff-symbol-referencer.hh"
/*
TODO:
{
Grob *me= unsmob_grob (smob);
Molecule mol;
+ Link_array<Grob> column_arr=
+ Pointer_group_interface__extract_elements (me, (Grob*)0, "columns");
+
+
+ if (!column_arr.size ())
+ return mol.smobbed_copy ();
+
+
+ Grob *b1 = Note_column::stem_l (column_arr[0]);
+ Grob *b2 = Note_column::stem_l (column_arr.top());
+
+ b1 = b1 ? Stem::beam_l (b1) : 0;
+ b2 = b2 ? Stem::beam_l (b2) : 0;
+
+
+ Spanner*sp = dynamic_cast<Spanner*> (me);
// Default behaviour: number always, bracket when no beam!
- bool par_beam = to_boolean (me->get_grob_property ("parallel-beam"));
+ bool par_beam = b1 && (b1 == b2) && !sp->broken_b() ;
+
bool bracket_visibility = !par_beam;
bool number_visibility = true;
else if (bracket == ly_symbol2scm ("if-no-beam"))
number_visibility = !par_beam;
- if (gh_pair_p (me->get_grob_property ("columns")))
- {
- Link_array<Grob> column_arr=
- Pointer_group_interface__extract_elements (me, (Grob*)0, "columns");
- Real ncw = column_arr.top ()->extent (column_arr.top (), X_AXIS).length ();
- Real w = dynamic_cast<Spanner*> (me)->spanner_length () + ncw;
-
- Real staff_space = 1.0;
- Direction dir = Directional_element_interface::get (me);
- Real dy = gh_scm2double (me->get_grob_property ("delta-y"));
- SCM number = me->get_grob_property ("text");
- if (gh_string_p (number) && number_visibility)
- {
- SCM properties = Font_interface::font_alist_chain (me);
- Molecule num = Text_item::text2molecule (me, number, properties);
- num.align_to (X_AXIS, CENTER);
- num.translate_axis (w/2, X_AXIS);
- num.align_to (Y_AXIS, CENTER);
- num.translate_axis (dir * staff_space, Y_AXIS);
+ Real ncw = column_arr.top ()->extent (column_arr.top (), X_AXIS).length ();
+ Real w = sp->spanner_length () + ncw;
+
+ Direction dir = Directional_element_interface::get (me);
+ Real dy = gh_scm2double (me->get_grob_property ("delta-y"));
+ SCM number = me->get_grob_property ("text");
+ if (gh_string_p (number) && number_visibility)
+ {
+ SCM properties = Font_interface::font_alist_chain (me);
+ Molecule num = Text_item::text2molecule (me, number, properties);
+ num.align_to (X_AXIS, CENTER);
+ num.translate_axis (w/2, X_AXIS);
+ num.align_to (Y_AXIS, CENTER);
- num.translate_axis (dy/2, Y_AXIS);
+ num.translate_axis (dy/2, Y_AXIS);
- mol.add_molecule (num);
- }
+ mol.add_molecule (num);
+ }
- if (bracket_visibility)
- {
- Real lt = me->paper_l ()->get_var ("stafflinethickness");
+ if (bracket_visibility)
+ {
+ Real lt = me->paper_l ()->get_var ("stafflinethickness");
- SCM thick = me->get_grob_property ("thick");
- SCM gap = me->get_grob_property ("number-gap");
+ SCM thick = me->get_grob_property ("thick");
+ SCM gap = me->get_grob_property ("number-gap");
- SCM at =gh_list (ly_symbol2scm ("tuplet"),
- gh_double2scm (1.0),
- gap,
- gh_double2scm (w),
- gh_double2scm (dy),
- gh_double2scm (gh_scm2double (thick)* lt),
- gh_int2scm (dir),
- SCM_UNDEFINED);
-
- Box b;
- mol.add_molecule (Molecule (b, at));
- }
+ SCM at =gh_list (ly_symbol2scm ("tuplet"),
+ gh_double2scm (1.0),
+ gap,
+ gh_double2scm (w),
+ gh_double2scm (dy),
+ gh_double2scm (gh_scm2double (thick)* lt),
+ gh_int2scm (dir),
+ SCM_UNDEFINED);
+
+ Box b;
+ mol.add_molecule (Molecule (b, at));
}
+
return mol.smobbed_copy ();
}
if (notey * d > (*offset + tuplety) * d)
*offset = notey - tuplety;
}
+
+ // padding
+ *offset += 1.0 *d;
+
+
+ /*
+ horizontal brackets should not collide with staff lines.
+
+
+ */
+ if (*dy == 0)
+ {
+ // quantize, then do collision check.
+ Real ss= Staff_symbol_referencer::staff_space (me);
+ *offset *= 2 / ss;
+
+ *offset = rint (*offset);
+ if (Staff_symbol_referencer::on_staffline (me, (int) rint (*offset)))
+ *offset += d;
+
+ *offset *= 0.5 * ss;
+ }
+
}
/*
Grob * me = unsmob_grob (smob);
Link_array<Note_column> column_arr=
Pointer_group_interface__extract_elements (me, (Note_column*)0, "columns");
- Spanner *sp = dynamic_cast<Spanner*> (me);
-
if (!column_arr.size ())
{
me->set_grob_property ("delta-y", gh_double2scm (dy));
me->translate_axis (offset, Y_AXIS);
-
- if (scm_ilength (me->get_grob_property ("beams")) == 1)
- {
- SCM bs = me->get_grob_property ("beams");
- Grob *b = unsmob_grob (gh_car (bs));
- Spanner * beam_l = dynamic_cast<Spanner *> (b);
- if (!sp->broken_b ()
- && sp->get_bound (LEFT)->column_l () == beam_l->get_bound (LEFT)->column_l ()
- && sp->get_bound (RIGHT)->column_l () == beam_l->get_bound (RIGHT)->column_l ())
- me->set_grob_property ("parallel-beam", SCM_BOOL_T);
- }
return SCM_UNSPECIFIED;
}
return d;
}
-void
-Tuplet_bracket::add_beam (Grob*me, Grob *b)
-{
- me->add_dependency (b);
- Pointer_group_interface::add_element (me, "beams",b);
-}
-
void
Tuplet_bracket::add_column (Grob*me, Item*n)
{
if (started_span_p_arr_[j])
Tuplet_bracket::add_column (started_span_p_arr_[j], dynamic_cast<Item*> (i.elem_l_));
}
- else if (Beam::has_interface (i.elem_l_))
- {
- /*
- TODO:
-
- ugh, superfluous. Should look at
-
- tuplet -> note-column -> stem -> beam
-
- to find the beam(s) of a tuplet
- */
-
- for (int j = 0; j < started_span_p_arr_.size (); j++)
- if (started_span_p_arr_[j])
- Tuplet_bracket::add_beam (started_span_p_arr_[j],i.elem_l_);
- }
}
void
input feta-accordion;
input feta-custodes;
else:
-% input feta-bolletjes;
-% input feta-banier;
+ input feta-bolletjes;
+ input feta-banier;
% input feta-eindelijk;
% input feta-klef;
% input feta-toevallig;
% input feta-schrift;
% input feta-haak;
- input feta-timesig;
+ %input feta-timesig;
% input feta-pendaal;
% input feta-accordion;
fi
--- /dev/null
+% Gray font for LJ with proofsheet resolution 150 pixels per inch.
+% Each pixel is represented by a 4x4 square, with 4/16 of the dots on.
+
+
+font_identifier "GRAYLJ";
+
+boolean lightweight;
+
+input grayf
tuplet_dy tuplet_dx div tuplet_gapx mul /tuplet_gapy exch def
- 0 0 moveto
- 0 tuplet_h dir mul lineto
+ 0 tuplet_h neg dir mul moveto
+ 0 0 lineto
tuplet_dx tuplet_gapx sub 2 div
- tuplet_dy tuplet_gapy sub 2 div tuplet_h dir mul add lineto
+ tuplet_dy tuplet_gapy sub 2 div lineto
tuplet_dx tuplet_gapx add 2 div
- tuplet_dy tuplet_gapy add 2 div tuplet_h dir mul add moveto
- tuplet_dx tuplet_dy tuplet_h dir mul add lineto
+ tuplet_dy tuplet_gapy add 2 div moveto
tuplet_dx tuplet_dy lineto
+ tuplet_dx tuplet_dy tuplet_h dir neg mul add lineto
stroke
} bind def
-/difficult_draw_ez_ball % ch letter_col ball_col font
+/draw_ez_ball % ch letter_col ball_col font
{
% font
findfont 0.7 scalefont setfont
} bind def
% Simple, but does it work everywhere?
+% Han-Wen reports that one printer (brand?) at cs.uu.nl chokes on this,
+% reverted for now -- jcn
+%
% The filled circles are drawn by setting the linewidth
-% to 2*radius and drawing a point. Is that (defined to be)
-% a nice filled circle?
-/draw_ez_ball % ch letter_col ball_col font
+% to 2*radius and drawing a point.
+/simple_draw_ez_ball % ch letter_col ball_col font
{
% font
findfont 0.85 scalefont setfont
(if (equal? "8" (substring cl (- l 1) l))
(begin
(if (equal? "^" (substring cl (- l 2) (- l 1)))
- (set! oct 7)
- (set! oct -7))
+ (set! oct -7)
+ (set! oct 7))
(set! cl (substring cl 0 (- l 2)))))
'tuplet-bracket-interface
"A bracket with a number in the middle, used for tuplets."
'(
- beams
columns
number-gap
delta-y
tuplet-bracket-visibility
tuplet-number-visibility
- parallel-beam
thick
))
projects / lilypond.git / commitdiff