Thanks Werner and Mats for the comments. I've made some further changes
to give the output that Werner suggested and to fix, in addition, bugs
489 and 599.
Is there anyone out there with strong opinions regarding beamlets and a
largish example to test? We seem to be fairly close to releasing a
sta
2008/6/4 Ben <[EMAIL PROTECTED]>:
> The tie option seems to fail, when i enter a ~ to make a tie, it seems that
> when
> i try to translate it to a PDF file it only creates a .log file with an error
> in
> it. and no pdf.
Try again with this code
{b ~ b}
or show us another minimal example that f
The tie option seems to fail, when i enter a ~ to make a tie, it seems that when
i try to translate it to a PDF file it only creates a .log file with an error in
it. and no pdf.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/ma
This is a known problem that has not made it into the bug tracker, as
far as I can see.
See http://lists.gnu.org/archive/html/lilypond-devel/2007-04/msg00136.html
Also, as you can see later in the same thread, it doesn't help to add
the bar engraver
to the context. Here comes a somewhat modified
Valentin Villenave wrote:
2008/5/29 Steven McDougall <[EMAIL PROTECTED]>:
%% grace note makes voiceOne go stems down
Thanks Steven,
I've added it as
http://code.google.com/p/lilypond/issues/detail?id=630
I hope you realize, however, that strictly speaking your example is not corre
2008/5/29 Steven McDougall <[EMAIL PROTECTED]>:
> %% grace note makes voiceOne go stems down
Thanks Steven,
I've added it as
http://code.google.com/p/lilypond/issues/detail?id=630
I hope you realize, however, that strictly speaking your example is not correct;
the good syntax (due to some known
Issue 630: non-synchronized grace note makes voiceOne go stems down
http://code.google.com/p/lilypond/issues/detail?id=630
New issue report by v.villenave:
\version "2.11.47"
\relative c''
{
<< { \grace b8 c c c c } \\ { g g g g } >>
}
% This (incorrect) code produces some warnings, and both
%
Issue 60: beam multiplicity changing on rests
http://code.google.com/p/lilypond/issues/detail?id=60
Comment #4 by lemzwerg:
The old one IMHO. Reason: The length of the `longest' element under
the beam (in the
case of the second beam it's the r16 rest) should not have a larger
`value' than the
While you are looking at the beaming rules. Have you by chance looked
into the
code that deals with subdivided beams. If so, could you also take a look
at issues 11, 489
and 599? There have also been several discussions on the mailing list
related to
the strange interaction between beatLength,
Issue 60: beam multiplicity changing on rests
http://code.google.com/p/lilypond/issues/detail?id=60
Comment #3 by joeneeman:
I've made some changes to beaming patterns in the dev/jneeman branch.
This improves
the results in many situations, but there is one in which I'm not sure
what the
output
10 matches
Mail list logo
