The following example produces heavy tie collisions:
c1 d f g ~ c d f g
I think the following algorithm handles ties between chords
gracefully:
For an up-tie, first check the left chord. If the start note is the
lower note of a second interval, shorten the tie. Then check the
right
Here my algorithm again, this time with images.
Werner
==
Preliminaries:
The input order is the accidentals from top to down, subject to
some reordering in rule 0.
In the following, a `second' interval is
one small comment: in some cases there is not much difference
between lily and your algorithm. Lily doesn't yet use accurate
bboxes for the naturals, so it won't squash them as close your
solution.
I've mentioned this already in the algorithm version with images.
Note that the images show
I don't know whether this has been reported already, but with tight
spacing (i.e. setting `shortest-duration-space' to a small value),
both the left and right bearing values of measure numbers are far too
big. They should shrink also.
Werner
c! cis has overlapping accidentals. Can I make them apart? The
code for shifting accidentals which you've shown me previously doesn't
work: Both accidentals are shifted at the same time.
Of course, the optimal solution would to fix this particular problem.
Werner
I don't know whether this has been reported already, but with tight
spacing (i.e. setting `shortest-duration-space' to a small value),
both the left and right bearing values of measure numbers are far too
big. They should shrink also.
A follow-up: My observation is not always true, but
I don't know whether this has been reported already, but with
tight spacing (i.e. setting `shortest-duration-space' to a small
value), both the left and right bearing values of measure
numbers are far too big. They should shrink also.
A follow-up: My observation is not always
An invisible bar line should really be invisible, but it currently
influences spacing, which is bad IMHO. Can you fix this?
How did you make it invisible? Did you use \bar
Yes, following the 1.5.xx instructions.
or did you use any of the more general methods described in the
section
I get the following error while doing `make all':
...
Processing dot-column-interface ...
Processing dots-interface ...
Processing dynamic-interface ...
Processing fing]]
scm_unprotect_object called on unprotected object
make[2]: *** [out/lilypond-internals.nexi] Error 134
rm
[CVS 2002-08-16 00:18]
The code below shows a recent error with padding: The values are
twice as big as they should.
Werner
==
\score {
\context Voice \notes \relative c'' {
\property
Werner Lemberg [EMAIL PROTECTED]
* Documentation/user/lilypond-book.itely: Remove empty
@cindex which makes texindex producing scrap.
==
--- lilypond-book.itely Thu Aug 15 00:46:05 2002
+++ lilypond-book.itely.new
I know there is something fishy going on (I noticed the checksum
errors), but I don't really know how to find the culprit. Can you
investigate?
The problem is that def_triangle calls `set_char_box' without sharp
variables:
set_char_box(0, ((x3-x1-kern)*fac+pent#)*xs,hei*fac,hei*fac);
It has staff-position 2, but Y-coordinate 1.0. The distinction is
confusing at times, but I guess we have to learn with it.
Indeed, I've mixed this up. Thanks for the clarification.
But how do I know which is which? This should be clearly stated in
the manual.
Werner
The files cxx-function-smob.{cc,hh} haven't been really removed...
Werner
___
Bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond
Saying \lilypondfile[noindent]{foo.ly} fails (where `foo.ly' isn't a
fragment but a complete .ly file without a \paper block). Reason is
that an `indent' keyword in a global \paper block (i.e., not inside of
\score) inserted by lilypond-book is ignored by LilyPond.
BTW, the same is true for a
I cannot see any difference between
\begin[noquote]{lilypond}
and
\begin{lilypond}
Oops! Here a patch. I forgot to implement `noquote' for LaTeX mode,
sorry. I'll add it soon to the CVS.
Werner
PS: I plan to get rid of the `eps' option, replacing it with an
`inline'
In lilypond 1.6.6, using dvips(k) 5.90a (from TeX Live 7), I find that
music-drawing-routines.ps is not being found. I added -d -1 to the
dvips invocation in ly2dvi, and found that it was searching for a
directory name `dvips' instead of `ps':
[...]
I don't understand why this used to
Trying xdvi -debug -1 shows that it is not reading the TEXPSHEADERS
environment variable at all. Bizarre.
Can you analyze this? What xdvi environment variable should be read
for TeX PS header files?
Werner
___
Bug-lilypond mailing list
I don't understand how to run this program. I followed the set up
instructions, but now I am stuck. Can you please explained it to
me. I looked on the web site but I didn't understand all of the
terms. I am also a blind computer user so can you explain what to
do and how to go about
I was explained by Werner Lemberg that harmonics never get
accidentals.
I have been proven to be wrong -- but this has already been discussed
on the list. Some publishers don't use accidentals, but it seems that
the majority does. Please make it an option, and the default should
From: Dr A V Le Blanc [EMAIL PROTECTED]
Subject: convert-ly does not convert to 1.9.0 or later
Date: Wed, 24 Mar 2004 07:57:49 +
I have quite a lot of lilypond source that I did back in the
1.3 and 1.6.6 days. I have almost nothing that convert-ly will
process, since it usually produces
I added this to the bug cvs [...]
It would be great if you can store JPG images also which show the
problem!
Werner
___
Bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond
It would be great if you can store JPG images also which show the
problem!
it's a better idea to use lilypond or lilypond-book to do this, then
we can see what happens to each bugs for every release.
But sometimes it is difficult to describe a problem with words. To
compare newer
It would be great if you can store JPG images also which show the
problem!
I use .png instead.
Yes, of course. A typo of mine.
I use the convention that if I submit something as clef-change.ly,
I upload clef-change.png demonstrating the problem, if appropriate.
Thanks, I got them. I
BTW, is there a preferred date format how do you extract that
easily with CVS?
I just take the ChangeLog timestamp which normally is precise enough
-- optimally, you should refer to the ChangeLog revision number.
Werner
___
bug-lilypond
I wrote:
I ask for yet another refinement: Do a zoom at the problematic spot
and crop the image around the buggy detail [...]
A good example is grace-accidental-spacing.ly: The current image (as
of Apr. 28th) doesn't really show the problem since the relevant
distances are already within
This one has pretty much to do about taste. Your suggestion sounds
sensible, but do you have a hand-engraved example of this behaviour?
(this would support the claim that you have a good taste :) You
wouldn't need to provide a scan of the score; just adding a texidoc
notice telling which
BTW, the same goes for multivoice-rest-position2. It's not 100%
obvious (to me at least) that it really is a bug; I can imagine that
the coders could be more motivated to fix the problem if you've done
some research that shows that your suggestion is common practise.
It's quite difficult to
I agree that using cvs for uploading png may seem a bit strange. But
it works and is very simple. cvs add -kb foo.png is much easier
than using ftp. And the file will be downloaded automatically to .
during cvs update, which is much easier than having to open mozilla.
I fully second this.
%
% text-spanner-and-skips.ly
%
% [EMAIL PROTECTED]
%
\version 2.2.5
\header { texidoc =
Using skips as `anchors' for TextSpanner objects causes programming error
messages and badly rendered results if there isn't enough (natural?) space.
}
\score {
\notes \relative c' {
\override
[lilypond 2.2.5]
Just process one of those files (from the lilypond distribution after
`make all'; the size doesn't matter):
feta-braces20list.ly
feta-din10list.ly
feta-nummer10list.ly
no lilypond glyphs are shown!
Additionally, those files are not included in the
%
% fermata-rest-position.ly
%
% [EMAIL PROTECTED]
%
\version 2.2.5
\header { texidoc =
Fermatas over rests are positioned too high.
}
\score {
\notes \relative c' {
c1\fermata R1-\fermataMarkup
}
\paper {
indent = 0.0\mm
linewidth = 70.0\mm
}
}
% EOF
There should be a version identifier on the top page for
`lilypond-internals.info', like
This is the internal reference for lilypond version 2.3.11.
Werner
___
bug-lilypond mailing list
[EMAIL PROTECTED]
%
% set-global-staff-size.ly
%
% critical
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
Calling `set-global-staff-size' breaks `lilypond --format=tex ...'.
}
#(set-global-staff-size 13)
\score {
c'1
}
% EOF
%
% encoding.ly
%
% critical
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\encoding latin1
\header { texidoc =
The `\encoding' command doesn't set the proper encoding vector for
data in the \header block. This contradicts the manual which states
that `the encoding of the file can be set with
%
% fermata-legato.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
Slurs shouldn't end over the fermata.
}
\score {
\relative c' {
a'2( f4 a | b e c a | a1\fermata) |
}
\paper {
indent = 0.0\mm
linewidth = 70.0\mm
}
}
% EOF
%
% slur-accidental.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
Slurs and accidentals shouldn't collide.
The example also shows another buglet: The stem length of the third 16th
note is too short.
}
\score {
\relative c' {
g'16( f g d! g2. ~ | g1 ~ | g1 ~ | g1)
}
And even if I change the order, the `inputencoding' parameter is
still ignored (I get `BaSStuba' instead of `Baßtuba').
IIRC, this SS is a bug of the EC fonts' encoding.
EC font encoding is simply not latin-1. If you manage to make
lilypond use `latin1.enc' as the encoding vector,
EC font encoding is simply not latin-1.
We assumed that EC font encoding matches EC.enc, but that seems not
to be the case, or there are glitches?
Where is the problem? If you select EC.enc, you get the glyphs
exactly in the order needed for LaTeX's T1 encoding. Note that the
glyph names
I wrote:
You have to reencode the EC fonts. If I understand your intentions
correctly, you want to make the input encoding basically equal to
the output encoding, this is, for latin1, the glyphs at font
positions 0x20-0x8F and 0xA0-0xFF should be the same as the input
encoding values.
%
% text-spanner.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
There are various problems with text spanners broken across a line.
o Text which is too long sticks out to the right. To avoid this I
suggest that the edge-text property automatically breaks the text
at
%
% ottava-dotted.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
Ottava spanners should end after the dot of a dotted note.
}
OttavaBassa = { #(set-octavation -1)
\set Staff.ottavation = #8ba }
Loco = #(set-octavation 0)
\score {
\relative c,, {
\clef
%
% markup-space.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
It seems that some markup commands introduce unwanted horizontal space.
After the `+', there shouldn't be any space.
}
\score {
s1^\markup { \fontsize #-3 { \fraction \number 1 \number 4
%
% rest-clef.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
The position of whole rests must not change if followed by a clef.
}
\score {
\context Staff = i {
R1 | R1 | R1 | \break
R1 | R1 |
}
\context Staff = ii {
R1 | R1 | R1 \clef bass |
%
% ottava-clef.ly
%
% [EMAIL PROTECTED]
%
\version 2.3.11
\header { texidoc =
Ottava spanners end too early before a line break if the last musical
element is a (small) clef -- even in another staff.
}
OttavaBassa = { #(set-octavation -1)
\set Staff.ottavation = #8ba }
Ottava spanners should end after the dot of a dotted note.
Already reported as octaviation-dot.
Oops, sorry, missed that.
Werner
___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Hmm, you've apparently used EC.enc for the font conversion.
Yes, why is that Hmm?
`Hmm' means `thinking loud'. :-)
This uses glyph name `\hyphen' for position 0x2D, while lilypond's
latin1.enc uses `\minus'.
Yes, I think ISOLatin1 says 0x2D is MINUS, not HYPHEN, and EC is
Where should the slur end?
Added the bug as slur-fermata.ly.
If both the slur and the fermata are above the note, the order (from
bottom to top) is note - slur - fermata.
This is probably not so easy to catch, since, say, both fermata and
tenuto line belong into the same category of grobs.
Things are not 100% clear to me after reading the message thread. Is
this a real bug? Given that I have added the \encoding bug already.
Maybe it is the same bug, but the appearance is not the same:
\encoding is outside of \bookpaper, while `inputencoding' is within.
Werner
This is probably not so easy to catch, since, say, both fermata
and tenuto line belong into the same category of grobs. With an
added tenuto, the order is note - tenuto - slur - fermata.
This needs some thought.
What we probably need is something similar to the Unicode collation
[EMAIL PROTECTED] writes:
Additionally, those files are not included in the
notation-appendices.itely file.
These are severe bugs -- the user can't deduce the correct name for
those glyphs if needed for \musicglyph markup command.
what makes you think that they have to be accessed
I just want to report that my bug report
w.r.t. minimumVerticalExtent also affects lilypond 2.3.11. This
is a really serious issue IMHO. For convenience, I'm repeating it
here.
This is not a bug, but rather an unintended consequence of
compatibility feature. minimumVerticalExtent is
??? *You* told me in a previous mail to use the minimumVerticalExtent
property to solve my problem!
I seem to have lost that email. Are you sure?
Yes.
\set Staff.minimumVerticalExtent = #'(-10 . 10)
with
\override VerticalAxisGroup #'minimum-Y-extent = #'(-10 . 10)
in
I've tuned down the padding for fermatas; I hope it doesn't give
problems for other scripts.
Thanks. Will test soon.
Werner
___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
How about a duo for violin and cello, where the cello changes to
tenor clef every now and then, for example?
Well, in case the numbers of lines with and without changing clef are
equal, I would ignore the clefs.
Werner
___
bug-lilypond
The input below causes version 2.3.11 to crash (please ignore the
texidoc text :-). Appended is a backtrace of the first few levels.
Werner
==
%
% [EMAIL PROTECTED]
\version 2.3.11
\header { texidoc =
Whole rests
To recapitulate the issue: When I process a file with ghostscript 8.x
(8.13 or 8.14) installed, the horizontal metrics of all characters in
the PDF output are messed up and the characters are squished together.
The PS file from the same run, however, looks OK, whether I look at it
with
% important
% [EMAIL PROTECTED]
\version 2.3.16
\header { texidoc =
This example shows two problems:
. The end point of a broken slur before the break is taken too low
sometimes, causing an extreme curvature of the slur.
. Broken slurs and ties sometimes collide.
}
\score {
% important
% [EMAIL PROTECTED]
\version 2.3.16
\header { texidoc =
Slurs at the start or end must not touch a stem exactly at its top.
}
\score {
\relative c' {
a'2( f4 a | b e c a | a1\fermata) |
}
\paper {
indent = 0.0\mm
linewidth = 70.0\mm
}
}
% EOF
+ != scripts-stopped
the scripts-stopped symbol sticks out on the left side. Are you
really asking for a + sign in the number font?
Yes.
Werner
___
bug-lilypond mailing list
[EMAIL PROTECTED]
%
% [EMAIL PROTECTED]
\version 2.3.17
\header { texidoc =
Broken slurs must be have correct start and end points. Basically, they
should be handled as two separate slurs, and the only connection between
them is that the `continuation' slur has a starting point (vertically)
influenced by the
%
% [EMAIL PROTECTED]
\version 2.3.17
\header { texidoc =
The stem of a note produced with the \note command doesn't have the correct
length if the font size is changed.
}
\score {
\relative c' {
c1^\markup { \note #4 #1 \teeny { \note #4 #1 } }
}
\paper {
raggedright = ##t
}
% important
% [EMAIL PROTECTED]
\version 2.3.18
\header { texidoc =
The \transpose syntax is not adequate for horn (shame on you, Hanwen :-)
While horn in F written with a treble clef has to be notated a fifth
higher, it must be written a fourth lower if a bass clef is used.
I also suggest to
The purpose of using bass clef is making parts easier to read by
eliminating ledger-lines. Old notation defeats the purpose.
Sadly, this bad practice is even perpetuated by some notation
handbooks who advocate it on the grounds of being unambiguous.
(thus spoke the typographically inclined
[...] isn't it as simple as indicating somthing like \clef bass
\transpose c c' { ... } to make something old notation?
No. There is no means to make Lilypond handle transposition in treble
clef differently to transposition in bass clef. This must be done
automatically.
In any event, I
No. There is no means to make Lilypond handle transposition in
treble clef differently to transposition in bass clef. This must
be done automatically.
try
\override OctavateEight #'transparent = ##t
\clef F_8
(or F^8, I forgot).
This is the manual solution...
Werner
What I want is that a new property is added:
\set Voice.transposeClefs = #'(treble . 0% as-is, default
bass . -7) % octave down
\transpose f c' \sounding
This should then yield the same result as \notated.
The amount of tuning that is
[The last mail to bug-lilypond to keep the thread intact.]
I think I now understand what you mean. Am I right if your wish is
semantically equivalent to telling lilypond to automatically convert
all occurrences of \clef F to \oldBassClef when transposing?
Yes.
In this case, I don't agree
[Resending, with uuencoded image.]
%
% [EMAIL PROTECTED]
\version 2.3.18
\header { texidoc =
\transposition, positioned in a transposed voice, then used in another
transposed voice, gives wrong results. As can be seen in the example,
the first note is apparently handled correctly, but the
Are you saying that the trick used in \verb is bad or just that
we should never mention the example below in any documentation
or that we should use the \verb trick but handle pairing characters
specially?
The last one. All editors will benefit.
Werner
On second thought, I'm not convinced that it helps the users to add
special cases to the simple general rule of delimiters.
Well, I don't object to your simple implementation, I just suggest
that a warning should be added to the docs that paired characters
should be avoided.
Werner
One of the problems I foresee is that we don't have the exact
dimensions of the scripts but only the bbox. This can make a big
difference. For example, Typically the + gets moved too far, while
the accent gets moved too little.
We probably have to introduce something better than the bbox,
I think the current behaviour is in line with the way relative mode
usually works.
Sigh. Yes, it is. Please forget everything. I mistakenly assumed
that \tag skips music, which is wrong of course.
Again, thanks for help.
Werner
___
[CVS 2004-09-30 18:13]
`make dvi' in Documentation/user fails. During the processing of
lilypond.texi the following error occurs:
./lily-391587254.tex:47: Undefined control sequence
Reason is that \nopagebreak doesn't exist for texinfo. Since lilypond
code should work with all TeX flavours
The following means some work for the documentation meister.
Theoretically, I could do it by myself, but then it doesn't have any
didactical purpose :-)
texinfo files are very limited w.r.t. input encodings. Currently,
latin1 is the best choice -- in reality, even this is not handled
BTW, it is better not to name the file tex/texinfo.cnf but, say,
Documentation/user/latin1.itexi, and it then is included in all
texinfo files
Urgh:
BTW, it is better not to name the file tex/texinfo.cnf but, say,
Documentation/user/latin1.itexi, and include this file in all
texinfo
%
% [EMAIL PROTECTED]
\version 2.3.20
\header { texidoc =
The stacking order of the end of a slur and a fermata is not correct
sometimes.
}
\score {
\relative c'' {
r2 c4--( e | f4 b-- a e | d4 b e2 | e1--\fermata)
}
\paper {
indent = 0.0\mm
raggedright = ##t
}
}
% EOF
% important
% [EMAIL PROTECTED]
\version 2.3.20
\header { texidoc =
A spanner which ends or starts at a whole rest doesn't work. This feature
is essential for instrument parts.
}
\score {
\relative c' {
\override TextSpanner #'edge-text = #'(foo . bar)
c1\startTextSpan | R1 | R1 | R1
I think the most practical solution is not to use accented letters
in the documentation at all.
But this is a lame solution... With my attached stuff latin-1 is
supported quite well.
BTW, it is better not to name the file tex/texinfo.cnf but, say,
Documentation/user/latin1.itexi, and it then
I got the following in lily2.bmp.
Uh, oh, don't send images in BMP format, especially if they are so
big! Using the PNG format, for example, I can compress your 240kByte
image into 10kByte!
Werner
___
bug-lilypond mailing list
[EMAIL
Maybe we should make a TeX.def, Werner?
I don't think so. What shall it contain? Whatever we select it is
wrong. :-/ Your fix for lilyponddefs.tex is the right kludge for the
moment IMHO.
Werner
___
bug-lilypond mailing list
[EMAIL PROTECTED]
The `--header' option of lilypond isn't documented in the texinfo
manual.
Werner
___
bug-lilypond mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
With fontencoding set to T1 (for example with \encoding TeX it
seems to be default) at least on cygwin ecrm1000 is looked for,
despite there is no references in the tex file created. I think
this is because the default roman font maps to it and the default
font is always created, or there
Because it seems that it's not installed automatically with
lilypond. The question is: in what package should it be?
The TeX fallback font `ecrm1000' is only needed in TFM format, since
we select T1 encoding to get the proper font mapping, but not a single
font used in `t1cmr.fd' is accessed
The TeX fallback font `ecrm1000' is only needed in TFM format,
since we select T1 encoding to get the proper font mapping, but
not a single font used in `t1cmr.fd' is accessed actually. IMHO
it would be fully sufficient to do
ln -s ecrm10.tfm ecrm1000.tfm
which doesn't do any
%
% [EMAIL PROTECTED]
\version 2.5.0
\header { texidoc =
The beam in the music snippet below should be below the notes.
}
\relative c'' {
\time 2/4 r8 a[ a' a,] |
}
\layout {
raggedright = ##t
}
% EOF
==
begin 644
% important
% [EMAIL PROTECTED]
\version 2.5.1
\header { texidoc =
The decrescendo spanner is far too long if it is used simultaneously
with a text string attached to a skip.
}
{ s1 | s1^This is a very long text string | s1 }
{ c'1\ | c'1\! | R1 }
\paper {
raggedright = ##t
}
%
% critical
% [EMAIL PROTECTED]
\version 2.5.1
\header { texidoc =
The note head doesn't appear in the \tempo command. Instead, there are
nasty `programming error' warnings.
}
{
\tempo 2=92
c'
}
% EOF
___
bug-lilypond mailing list
[EMAIL
Hi! As a small Christmas present to you all (Xmas is celebrated on
the 24th here in Sweden), I found this example. Looks a bit weird
to me. I'm not 100% sure if it's a bug though, perhaps it's
supposed to look like this. Any opinions?
Actually, this example isn't that bad. It's quite
I'm not sure if this is too nebulous to be counted a bug but here
are some representative pdf sizes from the examples.html pages of
2.5.10 and 2.4.2
This seems to be a bug in ghostscript's ps2pdf program: It apparently
isn't able to do glyph subsetting if the CFF is a resource -- it
always
% important
% [EMAIL PROTECTED]
\version 2.5.19
\header { texidoc =
Ledger lines stay visible if the `transparent' option of a NoteHead
is set.
}
{
\override NoteHead #'transparent = ##t
d'''1
}
\paper {
raggedright = ##t
}
% EOF
\override NoteHead #'transparent = ##t
What if you also set the LedgerLineSpanner transparent?
This doesn't work:
\override LedgerLineSpanner #'transparent = ##t
Additionally, I don't get a warning that this property isn't accepted
by LedgerLineSpanner. IMHO a bug: *All* grobs should
No, not at all. The ledgers are drawn by the spanner around the
noteheads.
What is `the spanner around note heads'? The word `ledger' doesn't
appear at all in lilypond.texinfo; how shall Joe User know such
details?
To make a note head ledger-less, it has to be marked with the
no-ledgers
\override LedgerLineSpanner #'transparent = ##t
Additionally, I don't get a warning that this property isn't
accepted by LedgerLineSpanner. IMHO a bug: *All* grobs should be
made invisible by setting the `transparent' property.
bugreport, please.
My mistake. I was using the
BTW, what's the reason for putting NoteHead into `Voice' and
LedgerLineSpanner into `Staff'?
To avoid collisions between ledger lines of tightly spaced notes,
the spanner needs to know about *all* note heads at the same time.
This requires that it be at Staff level.
Aah. Document it!
% important
% [EMAIL PROTECTED]
\version 2.5.19
\header { texidoc =
The horizontal distance between ties and the start and end notes is too
small IMHO.
}
{
c'2 ~ c'2 |
}
\layout {
raggedright = ##t
}
% EOF
==
begin
% important
% [EMAIL PROTECTED]
% CVS version 2005-08-28 11:10
\version 2.7.6
\header { texidoc =
The brace connecting the staves in PianoStaff context have the wrong
size.
Besides that, the default distance to the third staff is far too
small.
}
\paper { raggedright = ##t }
\context
% critical
% [EMAIL PROTECTED]
% CVS version 2005-08-28 11:10
\version 2.7.6
\header { texidoc =
In the example below a tie is missing.
}
\paper { raggedright = ##t }
\relative c' {
g' b e4 ~ g b e8.[ a d f16]
}
% EOF
The brace connecting the staves in PianoStaff context have the
wrong size.
can't duplicate. Probably an installation problem.
Hmm, I just checked lilypond with strace, and I can't find anything
suspicious. Similarly, the compilation and installation process (from
scratch, as usual) was
\header { texidoc =
It seems that contexts within contexts confuse LilyPond's lyrics engine.
Starting with the second syllable in the second context, lyrics are no
longer centered below the note but left-aligned.
reportedin = 2.7.11'
}
\context Voice \relative c' {
1 - 100 of 495 matches
Mail list logo
