Issue 291 in lilypond: \glissando doesn't work properly with chords

Issue 291: \glissando doesn't work properly with chords http://code.google.com/p/lilypond/issues/detail?id=291 Comment #6 by lemzwerg: Thanks! I wasn't aware of this. Nice. So something like the following should be added to the glissando section in the documentation: I = \once \override Note

Issue 291 in lilypond: \glissando doesn't work properly with chords

Issue 291: \glissando doesn't work properly with chords http://code.google.com/p/lilypond/issues/detail?id=291 Comment #5 by trevorbaca: There's a special override to do just this: \override NoteColumn #'ignore-collision = ##t Note that all clashing note column warnings will disappear where t

Re: Strange cross-stave beam and slur behaviour with portato

On 9/1/07, Neil Puttock <[EMAIL PROTECTED]> wrote: > Hello, > > The portato sign is causing some strange behaviour with both beams and slurs > when a voice crosses staves. > > Unfortunately, I can't seem to replicate the beaming problem in a minimal > example, but it seems related to the following

Re: 2.11.30 segmentation fault

Joe Neeman escreveu: > On Saturday 01 September 2007 09:00, Trevor Bača wrote: >> On 8/31/07, Joe Neeman <[EMAIL PROTECTED]> wrote: >>> On Friday 31 August 2007 23:17, Trevor Bača wrote: Should I send the inputfile to either Joe or Han-Wen for testing against .31? >>> I'd be happy to take

Re: 2.11.30 segmentation fault

On Saturday 01 September 2007 09:00, Trevor Bača wrote: > On 8/31/07, Joe Neeman <[EMAIL PROTECTED]> wrote: > > On Friday 31 August 2007 23:17, Trevor Bača wrote: > > > Should I send the inputfile to either Joe or Han-Wen for testing > > > against .31? > > > > I'd be happy to take a look at it. > >

Issue 438 in lilypond: subdivideBeams sometimes fails

Issue 438: subdivideBeams sometimes fails http://code.google.com/p/lilypond/issues/detail?id=438 New issue report by lemzwerg: \version "2.11.31" \header { texidoc = " Setting @code{subdivideBeams} to @code{#f} should work in triplets also. Here is a counterexample. " } \relative c' { \set s

Issue 437 in lilypond: alignAboveContext doesn't work as expected

Issue 437: alignAboveContext doesn't work as expected http://code.google.com/p/lilypond/issues/detail?id=437 New issue report by lemzwerg: \version "2.11.31" \header { texidoc = " `Alias' contexts with the same name should have identical vertical staff offsets. Here is a counterexample. " } \c

Issue 436 in lilypond: keep-inside-line sometimes fails in ragged-right mode

Issue 436: keep-inside-line sometimes fails in ragged-right mode http://code.google.com/p/lilypond/issues/detail?id=436 New issue report by lemzwerg: \version "2.11.31" \header { texidoc = " In ragged-right mode, the grob with the largest horizontal extent should define the line length. Here is

Issue 291 in lilypond: \glissando doesn't work properly with chords

Issue 291: \glissando doesn't work properly with chords http://code.google.com/p/lilypond/issues/detail?id=291 Comment #4 by lemzwerg: The idea in comment #3 is probably a bad one... An easy work-around is to use something like this: \relative << { \oneVoice \stemDown f2 \glissando \stemNeutral

Issue 308 in lilypond: \once fails for Glissando grob properties before a rest

Issue 308: \once fails for Glissando grob properties before a rest http://code.google.com/p/lilypond/issues/detail?id=308 Comment #1 by lemzwerg: Doh. This actually works. My example above is flawed -- the \once is placed too early. Issue attribute updates: Status: Invalid -- You rec

Issue 435 in lilypond: degenerated broken ties in chords

Issue 435: degenerated broken ties in chords http://code.google.com/p/lilypond/issues/detail?id=435 New issue report by lemzwerg: \version "2.11.31" \header { texidoc = " Broken ties between chords must always be visible. Here is a counterexample where the ties degenerate to dots. " } \relative

Issue 345 in lilypond: broken tie in chord disappears

Issue 345: broken tie in chord disappears http://code.google.com/p/lilypond/issues/detail?id=345 Comment #1 by lemzwerg: This has been fixed somehow. However, it is currently (2.11.31) superseded by #434 and #435 Issue attribute updates: Status: Fixed -- You received this message beca

Issue 434 in lilypond: unwanted direction change of broken tie

Issue 434: unwanted direction change of broken tie http://code.google.com/p/lilypond/issues/detail?id=434 New issue report by lemzwerg: \version "2.11.31" \header { texidoc = " A broken tie must never change its direction. Here is a counterexample. " } \relative c'' { \time 4/4 bes1 ~ \break

Strange cross-stave beam and slur behaviour with portato

Hello, The portato sign is causing some strange behaviour with both beams and slurs when a voice crosses staves. Unfortunately, I can't seem to replicate the beaming problem in a minimal example, but it seems related to the following snippet where the portato mark causes the slur to be skewed: \

Re: 2.11.30 segmentation fault

2007/9/1, Trevor Bača <[EMAIL PROTECTED]>: > > Joe's looking at the inputfile, which is awesome. > > For future reference, is there any way to get an unstripped binary > (one with all the debug messages not commented out, right?) from the > website? Or is git the only way to go? (I've so far avoid

Regression: tuplet-properties.ly

Hi, I found a regression in 2.11.31 over 2.10.29 in "tuplet-properties.ly": The tuplet number of the second group collides with the stem of the middle note. Christian ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/li

Regression: trill-spanner-pitched.ly

Hi, I found the following regression in 2.11.31 in "trill-spanner- pitched.ly": The parentheses of the indicated pitch collide with the following note. Christian ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listin

Re: 2.11.30 segmentation fault

On 8/31/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > 2007/8/31, Trevor Bača <[EMAIL PROTECTED]>: > > Hi, > > > > Crossposted as Google #433. > > > > Running 2.11.30 on a relatively large file (110 measures of six staves > > with 4559 lines of total input) causes the following segmentation > >