Re: time engraved twice when starting with an acciaccatura
On Wed, Oct 6, 2010 at 5:39 PM, Frank lein wrote:
> % resulting pdf not OK: time (=5/4) is engraved twice,
> %the 'b' at different positions for the staffs
> %the acciaccatura between the two time
>
> \version "2.12.3"
>
> voiceA ={ \relative g' { a4 } }
> voiceBwithAcc = { \relative b, { \acciaccatura d8 d4 } }
>
> \score {
>\new PianoStaff <<
>\new Staff { \time 5/4 \key d \minor \voiceA }
>\new Staff { \time 5/4 \key d \minor \clef bass
> \voiceBwithAcc }
>>> % EndePino staff
> }
>
>
> % without \acciaccatura ... everthing is OK
> voiceB = { \relative b, { d4 } }
>
> \score {
>\new PianoStaff <<
>\new Staff { \time 5/4 \key d \minor \voiceA }
>\new Staff { \time 5/4 \key d \minor \clef bass \voiceB }
>>> % EndePino staff
> }
>
>
>
Submitted as Issue 1302. Thank you.
http://code.google.com/p/lilypond/issues/detail?id=1302
Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1302 in lilypond: time engraved twice when starting with an acciaccatura
Status: Accepted
Owner:
Labels: Type-Other
New issue 1302 by RalphBugList: time engraved twice when starting with an
acciaccatura
http://code.google.com/p/lilypond/issues/detail?id=1302
% resulting pdf not OK: time (=5/4) is engraved twice,
% the 'b' at different positions for the staffs
% the acciaccatura is betwwen the time marks
\version "2.12.3"
voiceA ={ \relative g' { a4 } }
voiceBwithAcc = { \relative b, { \acciaccatura d8 d4 } }
\score {
\new PianoStaff <<
\new Staff { \time 5/4 \key d \minor \voiceA }
\new Staff { \time 5/4 \key d \minor \clef bass
\voiceBwithAcc }
>> % EndePino staff
}
% without \acciaccatura ... everthing is OK
voiceB = { \relative b, { d4 } }
\score {
\new PianoStaff <<
\new Staff { \time 5/4 \key d \minor \voiceA }
\new Staff { \time 5/4 \key d \minor \clef bass \voiceB }
>> % EndePino staff
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 506, or something similar, can still occur
Greetings, Keith -
On Tue, Sep 21, 2010 at 8:51 PM, Keith E OHara wrote:
> % Something like issue 506 can still be observed.
> %
> % Relative to the original report for issue 506,
> % remove the slur, and add an accent with a
> % forced direction. The beam is badly placed.
> %
> % I did *not* find this during normal use, but
> % while testing a workaround for a different bug.
> % Small changes avoid the bug. In this example, either
> % move the accent, or put the slur back in.
> % Maybe just file this under 506, so we know there
> % are limits to that fix?
>
> \version "2.12.3"
> % version 2.13.33 gives visibly the same output
>
> \paper { ragged-right = ##t }
> \new PianoStaff <<
> \new Staff = rh { s1 }
> \new Staff = lh \relative c {
> \clef bass
> %
> % LilyPond reports 'programming error: Grob direction
> % requested while calculation in progress.'
> % Inserting
> % \stemDown
> % removes this error report, but still produces
> % a badly-placed beam, very similar to original 506.
> %
> e16-\markup{a}_> b'
> \change Staff = rh
> g' b
> }
> %{%}>>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
This has been accepted as Issue 1300. I apologize for the long delay.
Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1300 in lilypond: Badly placed cross-staff beam, similar to Issue 506
Status: Accepted
Owner:
Labels: Type-Collision
New issue 1300 by RalphBugList: Badly placed cross-staff beam, similar to
Issue 506
http://code.google.com/p/lilypond/issues/detail?id=1300
% Something like issue 506 can still be observed.
%
% Relative to the original report for issue 506,
% remove the slur, and add an accent with a
% forced direction. The beam is badly placed.
%
% I did *not* find this during normal use, but
% while testing a workaround for a different bug.
% Small changes avoid the bug. In this example, either
% move the accent, or put the slur back in.
% Maybe just file this under 506, so we know there
% are limits to that fix?
\version "2.12.3"
% version 2.13.33 gives visibly the same output
\paper { ragged-right = ##t }
\new PianoStaff <<
\new Staff = rh { s1 }
\new Staff = lh \relative c {
\clef bass
%
% LilyPond reports 'programming error: Grob direction
% requested while calculation in progress.'
% Inserting
% \stemDown
% removes this error report, but still produces
% a badly-placed beam, very similar to original 506.
%
e16-\markup{a}_> b'
\change Staff = rh
g' b
}
%{%}>>
Attachments:
lilybug_506.png 3.0 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: strange collision of note and clef
On Wed, Oct 6, 2010 at 6:13 AM, Valentin Villenave
wrote:
> On Wed, Oct 6, 2010 at 10:52 AM, hans wrote:
> > In a piano-piece:
> > 4/4 time
> > right-hand plays truplet over half-note, in problem case quarter-note
> > half-note.
> > left-hand plays eights, changing clef every quarter-note.
> > In the problem-case the clef is written over the preceding eight.
>
> Wow, indeed. That is a serious bug, I'm forwarding this to the Bug Squad.
>
> \version "2.13.36"
> \new PianoStaff <<
> \new Staff \relative c' { \times 2/3 {g'4 a2}}
> \new Staff \relative c' {
>\clef bass fis,,8 cis' \clef treble c'' fis,
> }
> >>
>
> Hans: hopefully this bug will be fixed in a future version. In the
> meantime you may try adding a \break before this measure, hopefully
> this will help.
>
> Cheers,
> Valentin
>
> PS - Hans: as you can see, your bug could be demonstrated with a much
> smaller example, please keep that in mind when you encounter such
> problems. http://lilypond.org/tiny-examples.html
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
Thanks. This has been submitted as Issue 1301.
http://code.google.com/p/lilypond/issues/detail?id=1301&sort=-id&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary
Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1301 in lilypond: Strange collision of note and clef
Status: Accepted
Owner:
Labels: Type-Collision
New issue 1301 by RalphBugList: Strange collision of note and clef
http://code.google.com/p/lilypond/issues/detail?id=1301
In a piano-piece:
4/4 time
right-hand plays truplet over half-note, in problem case quarter-note
half-note.
left-hand plays eights, changing clef every quarter-note.
In the problem-case the clef is written over the preceding eight:
\version "2.13.36"
\new PianoStaff <<
\new Staff \relative c' { \times 2/3 {g'4 a2}}
\new Staff \relative c' {
\clef bass fis,,8 cis' \clef treble c'' fis,
}
Attachments:
toto.png 1.9 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
time engraved twice when starting with an acciaccatura
% resulting pdf not OK: time (=5/4) is engraved twice,
%the 'b' at different positions for the staffs
%the acciaccatura between the two time
\version "2.12.3"
voiceA ={ \relative g' { a4 } }
voiceBwithAcc = { \relative b, { \acciaccatura d8 d4 } }
\score {
\new PianoStaff <<
\new Staff { \time 5/4 \key d \minor \voiceA }
\new Staff { \time 5/4 \key d \minor \clef bass \voiceBwithAcc }
>> % EndePino staff
}
% without \acciaccatura ... everthing is OK
voiceB = { \relative b, { d4 } }
\score {
\new PianoStaff <<
\new Staff { \time 5/4 \key d \minor \voiceA }
\new Staff { \time 5/4 \key d \minor \clef bass \voiceB }
>> % EndePino staff
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
time engraved twice when starting with an acciaccatura
> I'm not top posting.
% resulting pdf not OK: time (=5/4) is engraved twice,
% the 'b' at different positions for the staffs
% the acciaccatura is betwwen the time marks
\version "2.12.3"
voiceA ={ \relative g' { a4 } }
voiceBwithAcc = { \relative b, { \acciaccatura d8 d4 } }
\score {
\new PianoStaff <<
\new Staff { \time 5/4 \key d \minor \voiceA }
\new Staff { \time 5/4 \key d \minor \clef bass \voiceBwithAcc }
>> % EndePino staff
}
% without \acciaccatura ... everthing is OK
voiceB = { \relative b, { d4 } }
\score {
\new PianoStaff <<
\new Staff { \time 5/4 \key d \minor \voiceA }
\new Staff { \time 5/4 \key d \minor \clef bass \voiceB }
>> % EndePino staff
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Autobeaming and cadenzas (was: bug-lilypond Digest, Vol 95, Issue 11)
On 10/5/10 11:44 PM, "David Kastrup" wrote: > Carl Sorensen writes: > >> On 10/5/10 5:50 PM, "Keith E OHara" wrote: >>> >>> If \cadenzaOff turns autobeaming on, then what about scores that turn off >>> autobeaming for the whole piece, but then (mis-)use short cadenzas? >> >> The CHANGES file informs the user that they will need to turn off >> autobeaming manually after the cadenza, as does the notation reference. >> >> I think this is the right thing to do. > > I think a revert would be more appropriate. I agree that a revert would be more appropriate. However, a revert would be very difficult to accomplish, because there is no easy way to save the "original" value. The value is only known in the translation stage as a context property, so we can't really save the value for use in the parsing stage. Right now, the benefit/time ration isn't high enough for me to code the revert. I'm fine to have an enhancement request to implement it as a revert, however. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1294 in lilypond: Version 2.13.35 does not properly represent lyric tie
Comment #6 on issue 1294 by percival.music.ca: Version 2.13.35 does not properly represent lyric tie http://code.google.com/p/lilypond/issues/detail?id=1294 Of course it's still a Critical bug if it's only a windows thing. I'm not trying to reject it; I'm trying to narrow it down for whoever works on this. Please don't quote pages of a pdf; giving a section name+number is more useful, as is a direct link the online docs if the problem is visible there: http://lilypond.org/doc/v2.13/Documentation/notation/common-notation-for-vocal-music#multiple-syllables-to-one-note On my lilypond-building computer, 2.13.35 on the command-line produces a pdf that's fine, but the GUB-compiled notation.pdf (and the pngs used to make the online docs) are broken. That makes me suspect a build issue with fonts. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash
"Valentin Villenave" wrote in message
news:aanlktim_zs=onfovmhv_2du_1zfh0kwumfe+swd3a...@mail.gmail.com...
On Tue, Oct 5, 2010 at 11:25 PM, Phil Holmes wrote:
The other issue is - all these test cases with multiple repeats are
artificial - the real question is - does it do long _real_ scores?
I always had the feeling (though nothing to document it) that LilyPond
is much better at compiling real-world scores, no matter how huge,
than {\repeat unfold 1} stressing tests. I've had no problem (on
GNU/Linux, that is) building either my or Nicolas' scores. Perhaps the
memory handling/garbage collection is better with real-world scores?
(e.g. with barchecks, music variables, different contexts being used,
etc?)
Similarly, here's what Han-Wen once told me when I tried compiling a
huge score imported with midi2ly:
http://lists.gnu.org/archive/html/lilypond-user/2006-10/msg00339.html
" A dirty midi file won't have note-ends aligned with barlines, which
means that the entire score will end up in one huge line without
breaks. This will undoubtedly stretch lilypond performance in
unexpected ways."
Cheers,
Valentin
I mentioned before that I'm slowly compiling a full Mikado score, which will
be about 150 pages long. It's currently 78 pages. It takes a while to
compile, but allocates lots more memory than I was using with the repeat
unfold stuff that crashed.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1299 in lilypond: ly/gregorian.ly needs minimum-Y-extent updated
Status: Accepted Owner: Labels: Type-Defect Priority-High Frog New issue 1299 by percival.music.ca: ly/gregorian.ly needs minimum-Y-extent updated http://code.google.com/p/lilypond/issues/detail?id=1299 convert-ly (GNU LilyPond) 2.13.36 Processing `gregorian.ly'... Applying conversion: 2.12.3, 2.13.0, 2.13.1, 2.13.4, 2.13.10, Not smart enough to convert vertical spacing has been changed; minimum-Y-extent is obsolete. Please refer to the manual for details, and update manually.2.13.16 [...] Change minimum-Y-extent to whatever the new thing is called, then give this file \version "2.13.16". ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1298 in lilypond: minimum-Y-extent must be updated manually
Status: Accepted Owner: Labels: Type-Documentation Priority-High Frog New issue 1298 by percival.music.ca: minimum-Y-extent must be updated manually http://code.google.com/p/lilypond/issues/detail?id=1298 Fix these examples; minimum-Y-extent is no longer used. Don't do anything in the translations, because they'll get the fix automatically the next time they update stuff. gperc...@gperciva-desktop:~/src/lilypond/Documentation$ grep minimum-Y-extent --exclude "misc/*" ???*/* -r notation/ancient.itely: \override VerticalAxisGroup #'minimum-Y-extent = ##f notation/ancient.itely: \override VerticalAxisGroup #'minimum-Y-extent = ##f notation/percussion.itely: \override VerticalAxisGroup #'minimum-Y-extent = #'(-4.0 . 5.0) notation/percussion.itely:\override VerticalAxisGroup #'minimum-Y-extent = #'(-3.0 . 4.0) notation/spacing.itely:\override VerticalAxisGroup #'minimum-Y-extent = #'(-6 . 6) snippets/engravers-one-by-one.ly: \override VerticalAxisGroup #'minimum-Y-extent = #'(-6 . 6) web/ly-examples/cary.ly: \override VerticalAxisGroup #'minimum-Y-extent = #'(10 . 10) web/ly-examples/cary.ly: \override VerticalAxisGroup #'minimum-Y-extent = #'(10 . 10) web/ly-examples/orchestra.ly:\override VerticalAxisGroup #'minimum-Y-extent = #'(-1 . 1) web/ly-examples/orchestra.ly:\override VerticalAxisGroup #'minimum-Y-extent = #'(-2 . 2 ) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash
hi, i used ubuntu, machines with 2 or 4 GB RAM resp. have to use minimal-breaking would be very disappointing... actually i just wanted to inform that some things not only happen in extreme artificial test cases... and that this breaking thing seems pretty much suboptimal in both optical result as in resource consumption... yours, arno On Wed, 06 Oct 2010 11:59:55 +0200, Valentin Villenave wrote: On Wed, Oct 6, 2010 at 11:30 AM, Arno Waschk wrote: well, i came across this problem while creating a *real-world* score, having 1600+ bars and using GBs of memory. it also showed horrible "compiling" times before Joe created his patches as well. while experimenting a bit with it, i could not find a significant difference between the real-world score, and a \repeat unfold 1600+ fake score. [I take it you forgot to include the list] Interesting. What operating system were you using? How much RAM? Also, one thing I probably should have mentioned is that the ly:minimal-breaking algorithm is often mandatory in such demanding compilations. Cheers, Valentin. -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: strange collision of note and clef
Am 06.10.2010, 12:13 Uhr, schrieb Valentin Villenave :
On Wed, Oct 6, 2010 at 10:52 AM, hans wrote:
In a piano-piece:
4/4 time
right-hand plays truplet over half-note, in problem case quarter-note
half-note.
left-hand plays eights, changing clef every quarter-note.
In the problem-case the clef is written over the preceding eight.
Wow, indeed. That is a serious bug, I'm forwarding this to the Bug Squad.
\version "2.13.36"
\new PianoStaff <<
\new Staff \relative c' { \times 2/3 {g'4 a2}}
\new Staff \relative c' {
\clef bass fis,,8 cis' \clef treble c'' fis,
}
Hans: hopefully this bug will be fixed in a future version. In the
meantime you may try adding a \break before this measure, hopefully
this will help.
Or tweak the horizontal extent of the clef in question. Add
\once \override Staff.Clef #'minimum-X-extent = #'(-1 . 2)
before the treble clef and find suitable values.
Best, Robert
Cheers,
Valentin
PS - Hans: as you can see, your bug could be demonstrated with a much
smaller example, please keep that in mind when you encounter such
problems. http://lilypond.org/tiny-examples.html
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1297 in lilypond: Polyphonic TrillSpanners should be stacked accordingly to their Voice's position
Comment #2 on issue 1297 by v.villenave: Polyphonic TrillSpanners should be stacked accordingly to their Voice's position http://code.google.com/p/lilypond/issues/detail?id=1297 As demonstrated by trill-spanner-auto-stop.ly demonstrates that by default, trillspanners are stacked and not aligned. trill-spanner-chained.ly does use \stopTrillSpan in order to chain the spanners. Perhaps the documentation could be more detailed/accurate? But you're right, we've had quite a number of issues with TrillSpanners, from issue 12 to issue 923... But I couldn't find one wrt polyphonic situations. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: strange collision of note and clef
On Wed, Oct 6, 2010 at 10:52 AM, hans wrote:
> In a piano-piece:
> 4/4 time
> right-hand plays truplet over half-note, in problem case quarter-note
> half-note.
> left-hand plays eights, changing clef every quarter-note.
> In the problem-case the clef is written over the preceding eight.
Wow, indeed. That is a serious bug, I'm forwarding this to the Bug Squad.
\version "2.13.36"
\new PianoStaff <<
\new Staff \relative c' { \times 2/3 {g'4 a2}}
\new Staff \relative c' {
\clef bass fis,,8 cis' \clef treble c'' fis,
}
>>
Hans: hopefully this bug will be fixed in a future version. In the
meantime you may try adding a \break before this measure, hopefully
this will help.
Cheers,
Valentin
PS - Hans: as you can see, your bug could be demonstrated with a much
smaller example, please keep that in mind when you encounter such
problems. http://lilypond.org/tiny-examples.html
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash
On Wed, Oct 6, 2010 at 11:30 AM, Arno Waschk wrote: > well, i came across this problem while creating a *real-world* score, having > 1600+ bars and using GBs of memory. it also showed horrible "compiling" > times before Joe created his patches as well. while experimenting a bit with > it, i could not find a significant difference between the real-world score, > and a \repeat unfold 1600+ fake score. [I take it you forgot to include the list] Interesting. What operating system were you using? How much RAM? Also, one thing I probably should have mentioned is that the ly:minimal-breaking algorithm is often mandatory in such demanding compilations. Cheers, Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1286 in lilypond: Page-breaking doesn't work properly when the last bar is incomplete
Updates: Summary: Page-breaking doesn't work properly when the last bar is incomplete Comment #2 on issue 1286 by v.villenave: Page-breaking doesn't work properly when the last bar is incomplete http://code.google.com/p/lilypond/issues/detail?id=1286 Thanks Joe! Updating title. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1297 in lilypond: Polyphonic TrillSpanners should be stacked accordingly to their Voice's position
Comment #1 on issue 1297 by paconet.org: Polyphonic TrillSpanners should be
stacked accordingly to their Voice's position
http://code.google.com/p/lilypond/issues/detail?id=1297
trillspans are difficult to manage in either case. Contraryly to what is
stated in the manual, consecutive trills do not align.
{
c' \startTrillSpan
c' \startTrillSpan
c' \startTrillSpan
c' \startTrillSpan
}
Attachments:
Pantallazo-1.png 4.5 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1297 in lilypond: Polyphonic TrillSpanners should be stacked accordingly to their Voice's position
Status: Accepted
Owner:
Labels: Type-Defect Priority-Medium
New issue 1297 by v.villenave: Polyphonic TrillSpanners should be stacked
accordingly to their Voice's position
http://code.google.com/p/lilypond/issues/detail?id=1297
% In the following example, the lower voice's trillspanner is placed
% *above* the upper voice's. It should be placed below, thus matching
% the lower/upper Voice layout.
\version "2.13.36"
\new Staff <<
\new Voice \relative c' { \voiceOne
a''1\startTrillSpan a\stopTrillSpan
}
\new Voice \relative c' { \voiceTwo
r2 a'\startTrillSpan a1\stopTrillSpan
}
% This is technically an Enhancement, but since the current output
% isn't ideal, I'm making it a Defect.
Attachments:
toto.png 1.2 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crash
On Tue, Oct 5, 2010 at 11:25 PM, Phil Holmes wrote:
> The other issue is - all these test cases with multiple repeats are
> artificial - the real question is - does it do long _real_ scores?
I always had the feeling (though nothing to document it) that LilyPond
is much better at compiling real-world scores, no matter how huge,
than {\repeat unfold 1} stressing tests. I've had no problem (on
GNU/Linux, that is) building either my or Nicolas' scores. Perhaps the
memory handling/garbage collection is better with real-world scores?
(e.g. with barchecks, music variables, different contexts being used,
etc?)
Similarly, here's what Han-Wen once told me when I tried compiling a
huge score imported with midi2ly:
http://lists.gnu.org/archive/html/lilypond-user/2006-10/msg00339.html
" A dirty midi file won't have note-ends aligned with barlines, which
means that the entire score will end up in one huge line without
breaks. This will undoubtedly stretch lilypond performance in
unexpected ways."
Cheers,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
