Beams over rests and concaveness

once \override Beam.concaveness = #+inf.0 g8[ r16 g''16] } <http://lilypond.1069038.n5.nabble.com/file/t4165/beam.png> Originally reported here: http://lilypond.1069038.n5.nabble.com/Beams-over-rests-and-concaveness-td227600.html So it seems that neither concaveness nor damp

Re: Subdivised beams bug

Hello Urs, James, and everybody else, I’ve finally come around and made an attempt at sensible bookkeeping of these issues by creating and closing some of the related issues that I think it supersedes as Duplicates. I hope that is consi

Re: Subdivised beams bug

Urs Liska-3 wrote > TL;DR: it's a known issue, and there's no reasonable hope to have it > fixed soon. Thank you Urs for all the explanations. I feel sorry I don't have the knowledges myself to help with the code... But LP is now my main engraving software which I start to use intensively. My on

Re: Subdivised beams bug

Am 07.09.2018 um 08:51 schrieb James: Hello On 06/09/18 21:28, Urs Liska wrote: TL;DR: it's a known issue, and there's no reasonable hope to have it fixed soon. Best Urs Does that mean there is a tracker for this, or do we need a new one created? There are a number of open issues, (at

Re: Subdivised beams bug

Hello On 06/09/18 21:28, Urs Liska wrote: TL;DR: it's a known issue, and there's no reasonable hope to have it fixed soon. Best Urs Does that mean there is a tracker for this, or do we need a new one created? James ___ bug-lilypond mailing list

Re: Subdivised beams bug

the problem is not *where* the beams are subdivided but *how*. That’s a bug, yes, see Urs’s reply. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Subdivised beams bug

Malte Meyn-3 wrote > The result (using LilyPond 2.19.82) is exactly what I would’ve expected. > I suppose your expectation is different so what did you expect? The automatic subdivised beam is 16th instead of 8th. Here is the problem and what I would have expected: \relative c'' { \set subdivi

Re: Subdivised beams bug

Am 06.09.18 um 20:57 schrieb foxfanfare: When the beat ends with a rest, the subdivised beam doesn't work correctly. The result (using LilyPond 2.19.82) is exactly what I would’ve expected. I suppose your expectation is different so what did you expect?

Subdivised beams bug

Hi all, I found a small bug while using the automatic beaming function. http://lilypond.org/doc/v2.19/Documentation/notation/beams.html#setting-automatic-beam-behavior See: \relative c'' { \set subdivideBeams = ##t % Set beam sub-group length to an eighth note \set baseMoment = #(ly:make

Re: Multiple beams too close to notehead

On Mon, Feb 1, 2016 at 4:02 AM, Urs Liska wrote: > Hi all, > > I've always found that beams with three or more beams look too tight, > but now reading Gould, p. 19 confirms that, and I consider this a > type-ugly bug: Thanks, Urs. This has been submitted as

Re: Multiple beams too close to noteheaD

> However, inferring from what she says about *two* beams and that a > third beam should be attached to the outside one would have to say > the "correct" distance would be to have the innermost beam *center* > on the line. That is: with the note a' the inner beam

Re: Multiple beams too close to noteheaD

Am 01.02.2016 um 10:15 schrieb Werner LEMBERG: >> Attached you'll find examples for three and four beams, and I expect >> this to continue with more beams. I have colored the ones too close >> in red and adjusted them (blue) to Gould's minimum distance. > Thank

Re: Multiple beams too close to noteheaD

> Attached you'll find examples for three and four beams, and I expect > this to continue with more beams. I have colored the ones too close > in red and adjusted them (blue) to Gould's minimum distance. Thanks for your analysis, to which I agree in general. However, I co

Multiple beams too close to notehead

Hi all, I've always found that beams with three or more beams look too tight, but now reading Gould, p. 19 confirms that, and I consider this a type-ugly bug: According to Gould outer beams starting with the third should move away from the notehead, and "beams should never be clo

Multiple beams too close to noteheaD

Hi all, I've always found that beams with three or more beams look too tight, but now reading Gould, p. 19 confirms that, and I consider this a type-ugly bug: According to Gould outer beams starting with the third should move away from the notehead, and "beams should never be clo

Re: French beams over rests cause segfault

"Jean Menezes da Rocha" wrote in message news:CALRb6h+_gWgeU1=6wruogawua7hsddya8zx0vsy97is7tci...@mail.gmail.com... I have seen, according to this [1], that Kastrup created a patch to address this issue. Is there any way I can apply this patch by now,

Re: French beams over rests cause segfault

I have seen, according to this [1], that Kastrup created a patch to address this issue. Is there any way I can apply this patch by now, or should I wait for a new development release containing a definitive solution? If this is not the right place/time to

Re: French beams over rests cause segfault

Thanks Simon, I am gonna take a risk and try to compile a patched version using the .diff file. Best regards! On Thu, Nov 5, 2015 at 11:52 AM, Simon Albrecht wrote: > On 05.11.2015 14:45, Jean Menezes da Rocha wrote: > >> I have seen, according to this

Re: French beams over rests cause segfault

On 05.11.2015 14:45, Jean Menezes da Rocha wrote: I have seen, according to this [1], that Kastrup created a patch to address this issue. Is there any way I can apply this patch by now, or should I wait for a new development release containing a defin

Re: French beams over rests cause segfault

Hello Jean, thanks for the additional info. Please always reply on-list, that way others can pick up the process etc. Yours, Simon On 03.11.2015 02:01, Jean Menezes da Rocha wrote: Now I see I haven't added some important details: I am running Lilypond 2.19.30 from Antergos Linux 64-bit. I

Re: French beams over rests cause segfault

On 03.11.2015 00:01, Jean Menezes da Rocha wrote: I'm not top posting. Hello, I may have stumbled upon a bug. Everytime a group of beamed notes ends with a rest, if I enable french-beaming the compilation is stopped by a segmentation fault. I can confirm that from 2.16 onward, so I created <

French beams over rests cause segfault

> I'm not top posting. Hello, I may have stumbled upon a bug. Everytime a group of beamed notes ends with a rest, if I enable french-beaming the compilation is stopped by a segmentation fault. this example: \version "2.19.30" \relative c'' { \override Stem.french-beaming = ##t c16[ d e r

Re: partcombine problem with double explicit beams and slurs [was: Re: three small bugs]

Thanks a lot. -- View this message in context: http://lilypond.1069038.n5.nabble.com/three-small-bugs-tp182794p182984.html Sent from the Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org

partcombine problem with double explicit beams and slurs [was: Re: three small bugs]

Hello Gilberto, On 27.10.2015 13:43, Gilberto Agostinho wrote: - no. 1: when two parts contain manual beams and slurs at the same point and one uses \partcombine, some warnings are outputs in the console: "unterminated beam" and "unterminated slur". It does output the mu

crossStaff, beams and tuplets [was: Re: three small bugs]

y? If one wants to use \crossStaff for a certain passage, then very likely he doesn't want beams and tuplets displaying there. The reference mentions that one should use \autoBeamOff but there are no mentions about tuplets. \version "2.19.28" \score{ \new PianoStaff <<

Re: Subdivided beams

On 4/23/15 10:49 AM, "Trevor Daniels" wrote: > >Urs Liska wrote Thursday, April 23, 2015 5:06 PM > > >> >> From the description it seems that LilyPond doesn't do that and can't >> easily be talked into doing it, so this seems an "embarrassing" bug. > >This was recently discussed on the user li

Re: Subdivided beams

sion > http://lilypond.org/doc/v2.19/Documentation/notation/beams.html#Selected-Snippets-12 > > According to Gould (sorry, I don't own the book, so no page number > available) the rhythmical organization is indicated by the number of > remaining beams in the subdivisions. Depending o

Re: Misplaced staccato dots on beams

I conclude from the patch mail, that this is going to be fixed soon. > PUSH: > > Keith OHara: staccato moves to avoid ledge on opposite side of staff > http://code.google.com/p/lilypond/issues/detail?id=4184 If that is true, it is amazing how quick you are! Thanks, Joram __

Misplaced staccato dots on beams (was: Piano voices)

Hi David, > The positioning of staccato dots is rather irregular--note, for example, > m. 70 (bottom staff) and m. 75. If this happens without any > intervention on your part, I think that there's an issue here. I think so, too. I reported it here with a minimal example: http://lists.gnu.org/arc

[LSR v2.18] "Making cross-staff beams look better" obsolete

Hi Squad, The folowing snippet : http://lsr.di.unimi.it/LSR/Item?id=508 is not needed anymore for v2.18. Not sure about deletion though. Cheers, Pierre ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilyp

Re: beams look ugly when using \autochange

Thanks for your message, Federico! Sorry but I did not realize this bug was already added, I am glad about it then. Take care, Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/beams-look-ugly-when-using-autochange-tp153470p158210.html Sent from the Bugs mailing

Re: beams look ugly when using \autochange

en engraving piano music that has a lot of staff changes for > instance (which means that each single one of the beams has to be manually > tweaked...). Thanks a lot! > it's been added in november: https://code.google.com/p/lilypond/issues/detail?id=3659 I guess that this blocks this issu

Re: beams look ugly when using \autochange

2013/11/7 David Nalesnik > On Wed, Nov 6, 2013 at 1:32 PM, Gilberto Agostinho < > gilbertohasn...@gmail.com> wrote: > > > When using \autochange, the slope of the beams look ugly against the > staff > > lines: > > > > It's not specifically a problem

Re: beams look ugly when using \autochange

Hello, Gilberto Agostinho wrote > When using \autochange, the slope of the beams look ugly against the staff > lines Gilberto Agostinho wrote > [...] this seems to be a problem with any staff changes. So does this > qualify as a bug? I personally think it doesn't look rig

Re: beams look ugly when using \autochange

So does anyone else agrees that this problem here should be added to the Issue Tracker? If so, could someone who has the permission to do so please add it there? Thanks a lot! Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/beams-look-ugly-when-using-autochange

Re: beams look ugly when using \autochange

Indeed this seems to be a problem with any staff changes. So does this qualify as a bug? I personally think it doesn't look right at all, and to manually tweak every single beam is a headache... Best, Gilberto -- View this message in context: http://lilypond.1069038.n5.nabble.com/beams

Re: beams look ugly when using \autochange

On Wed, Nov 6, 2013 at 1:32 PM, Gilberto Agostinho < gilbertohasn...@gmail.com> wrote: > When using \autochange, the slope of the beams look ugly against the staff > lines: > It's not specifically a problem with \autochange. You get the same behavior with manual staff ch

beams look ugly when using \autochange

When using \autochange, the slope of the beams look ugly against the staff lines: \version "2.17.29" \markup { When using autochange:} \markup { Not perfectly horizontal beams, conflicting with staff lines} \new PianoStaff { \autochange \relative c' { \time 2/4 gis16

Re: 2.17.19 - Ottava with cross-staff = messed up beams

com/p/lilypond/issues/detail?id=3385&thanks=3385&ts=1369898108 Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/2-17-19-Ottava-with-cross-staff-messed-up-beams-tp146480p146483.html Sent from the Bugs mailing list archive at Nabble.com. _

2.17.19 - Ottava with cross-staff = messed up beams

> I'm not top posting. % On the stable 2.16.2, this is fine, but on the unstable 2.17.19, % the following short example results in extremely corrupted / % messed up stems. Bug? chUp = \change Staff = "upper" chDn = \change Staff = "lower" \new PianoStaff << \new Staff = "upper"

Re: Kneed beams when changing stem direction \once

Eluze gmail.com> writes: > > I don't understand why they should - aren't you overriding the default stem > direction for just one note?? > Oops. Good point. Guess I jumped the gun a little submitting that here... DR ___ bug-lilypond mailing list bu

Re: Kneed beams when changing stem direction \once

m direction for just one note?? the first two notes without an \override will have the beam above the notes. or can you add a picture where this behaves wrongly! Eluze -- View this message in context: http://lilypond.1069038.n5.nabble.com/Kneed-beams-

Kneed beams when changing stem direction \once

> I'm not top posting. %{ In the example below, the two pairs of beamed eighth notes should appear identical due to the \override command; however, it appears that the \once command preceding the \stemDown for the first pair is preventing that. %} \version "2.16.1" { \override Beam #'auto-knee-

Re: [musicxml2ly] beams and lost lyric syllables

Hello, 2012/10/6 pls > I forgot to mention that syllables don't get lost when musicxml2ly is used > with the option --no-beaming. But this is only a dirty workaround as > LilyPonds' autobeaming algorithm overrides the beaming information provided > by the .xml-file. Beyond that we implemented a

Re: [musicxml2ly] beams and lost lyric syllables

10.2012 um 23:06 schrieb pls: > Hey all, > > syllables under beamed notes are swallowed by musicxml2ly (LilyPond v2.17.3). > This seems to be a close relative of Issue 2881. > > Test File: > https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSui

[musicxml2ly] beams and lost lyric syllables

Hey all, syllables under beamed notes are swallowed by musicxml2ly (LilyPond v2.17.3). This seems to be a close relative of Issue 2881. Test File: https://github.com/Philomelos/lilypond-musicxml2ly-dev/blob/master/MusicXML-TestSuite/beams-lyrics.xml Result of the conversion of the test file

Re: [2.15.36] A hidden note blocks beams from drawing

Hello, 2012/9/28 Trevor Daniels > James Harkins wrote Friday, September 28, 2012 8:08 AM > > The beams on the two e's are omitted in this tiny example (version > 2.15.36). > > \relative c' { r8 \hideNotes f8 \unHideNotes e8. e16 e2 } > > The beams are

Re: [2.15.36] A hidden note blocks beams from drawing

James Harkins wrote Friday, September 28, 2012 8:08 AM > The beams on the two e's are omitted in this tiny example (version 2.15.36). > > \relative c' { r8 \hideNotes f8 \unHideNotes e8. e16 e2 } > > > The beams are *not* omitted in this tiny example. >

Re: Beams of grace notes collide with tie in staff size5 1

Reinhold, Thank you for reporting this. It may be related to Issue 1627. It has been added to the tracker: http://code.google.com/p/lilypond/issues/detail?id=2775&thanks=2775&ts=1345945784 By the way, I noticed that the file is listed a version 2.17.0 but I did not see that version on the website

Beams of grace notes collide with tie in staff size5 1

I have a staff with two voices (actually, two part-combinedvoices). In the attached example, the beam of the grace in the second voice collides with the tie in the first voice, but only if I use staff size 15. In any other staff size, no collision occurs. Also, the stems of the grace notes ar

Re: Collision between note beams and chords using tabFullNotation

Mark Brophy brophyworld.com> writes: > % This bug is a "tiny example" because nothing can be removed; the bug > % is a consequence of a dense set of eighth and sixteenth notes placed > % in guitar tablature using tabFullNotation. Thanks. Tiny enough to unambiguously show the problem is good.

Re: Collision between note beams and chords using tabFullNotation

ng tabFullNotation. % The bug causes a collision between the beams of the notes and chords % above in the second line; there are no collisions in the first line. \version "2.14.0" % necessary for upgrading to future LilyPond versions. << \chords {d1 a b:m fis:m g d g a } \new Tab

Collision between note beams and chords using tabFullNotation

> I'm not top posting. % This bug is a "tiny example" because nothing can be removed; the bug % is a consequence of a dense set of eighth and sixteenth notes placed % in guitar tablature using tabFullNotation. % The bug causes a collision between the beams of the notes and

Re: Issue 744 in lilypond: Cross-staff beams do not work well when including rests

Updates: Labels: Patch-review Comment #3 on issue 744 by d...@gnu.org: Cross-staff beams do not work well when including rests http://code.google.com/p/lilypond/issues/detail?id=744#c3 Patchy the autobot says: LGTM. ___ bug-lilypond

Re: Issue 744 in lilypond: Cross-staff beams do not work well when including rests

Comment #2 on issue 744 by mts...@gmail.com: Cross-staff beams do not work well when including rests http://code.google.com/p/lilypond/issues/detail?id=744 The patch I've proposed for this addresses part of the issue. The side of the beam that the rest falls on is another issue: here,

Re: Issue 744 in lilypond: Cross-staff beams do not work well when including rests

Updates: Labels: Patch-new Comment #1 on issue 744 by mts...@gmail.com: Cross-staff beams do not work well when including rests http://code.google.com/p/lilypond/issues/detail?id=744#c1 Brings beamed rest closer to cross staff beam. http://codereview.appspot.com/5908043

Re: Issue 2169 in lilypond: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams

Updates: Status: Verified Comment #12 on issue 2169 by colingh...@gmail.com: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams http://code.google.com/p/lilypond/issues/detail?id=2169 Verifed that those commmits are in the repo and also that they

Re: Issue 2169 in lilypond: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams

Comment #11 on issue 2169 by tdaniels...@gmail.com: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams http://code.google.com/p/lilypond/issues/detail?id=2169 Sorry Colin. There were two: d74afd12749a9d1de0aaac200bb86658091f15c3

Re: Issue 2169 in lilypond: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams

Comment #10 on issue 2169 by colingh...@gmail.com: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams http://code.google.com/p/lilypond/issues/detail?id=2169 Trevor, could you supply a committish for this patch, please

Issue 2414 in lilypond: Midi back end handles lyrics and beams incorrectly

Status: Accepted Owner: Labels: Type-Defect New issue 2414 by philehol...@gmail.com: Midi back end handles lyrics and beams incorrectly http://code.google.com/p/lilypond/issues/detail?id=2414 Reported by Frank Steinmetzger: I just discovered that 2.14 produces different lyrics for PDF

Re: Issue 2169 in lilypond: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams

Updates: Status: Fixed Owner: tdaniels...@gmail.com Labels: -Patch-abandoned fixed_2_15_34 Comment #9 on issue 2169 by tdaniels...@gmail.com: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams http://code.google.com/p/lilypond/issues

Issue 2386 in lilypond: Beams with a Single Subdivision

Status: Accepted Owner: CC: njh...@gmail.com Labels: Type-Enhancement New issue 2386 by d8val...@gmail.com: Beams with a Single Subdivision http://code.google.com/p/lilypond/issues/detail?id=2386 I would expect that all four beams should be subdivided, but only the second beam in the bar

Re: \grace after \cadenzaOff suppresses auto-beams

Jean-Charles Malahieude writes: > Le 06/03/2012 01:04, Colin Hall disait : >> >> [...] >> >> Have you isolated a bug here? >> > > I'm not sure about it but, thanks to the Scheme tutorial I just > finished to translate I'm now not so blind: > > \displayMusic { >c1 >\cadenzaOn d1 e \cadenz

Re: \grace after \cadenzaOff suppresses auto-beams

Le 06/03/2012 01:04, Colin Hall disait : [...] Have you isolated a bug here? I'm not sure about it but, thanks to the Scheme tutorial I just finished to translate I'm now not so blind: \displayMusic { c1 \cadenzaOn d1 e \cadenzaOff f1 } and it looks like the D and E don't belon

Re: \grace after \cadenzaOff suppresses auto-beams

> > \appoggiatura b4 >> > \set Timing.measurePosition = #(ly:make-moment 0 4) >> >%%% subsequent stuff >> > >> > >> >...by setting the measurePosition *after* the grace/appoggiatura and >> >before the first "beat" of the measure, th

Re: \grace after \cadenzaOff suppresses auto-beams

asurePosition = #(ly:make-moment 0 4) > >%%% subsequent stuff > > > > > >...by setting the measurePosition *after* the grace/appoggiatura and > >before the first "beat" of the measure, the beams remain intact and > >the warning disappears. Huzzah. >

Re: \grace after \cadenzaOff suppresses auto-beams

irst "beat" of the measure, the beams remain intact and the warning disappears. Huzzah. But still "strange" if you consider the bar numbering (the same goes with your accidentals' problem): \relative c' { \override Score.BarNumber #'break-visibility = #'

Re: \grace after \cadenzaOff suppresses auto-beams

grace b8 \cadenzaOff \normalsize a4. gis8 e'8 e e e } hth Eluze Thanks for the input. I ended up using the \partial solution (in this case, \partial 1 ). As noted above, I got a warning but the beams came back. I tried putting the \grace inside the cadenza but that put i

Re: \grace after \cadenzaOff suppresses auto-beams

gis8 e'8 e e e } hth Eluze Thanks for the input. I ended up using the \partial solution (in this case, \partial 1 ). As noted above, I got a warning but the beams came back. I tried putting the \grace inside the cadenza but that put it

Re: \grace after \cadenzaOff suppresses auto-beams

zaOff-suppresses-auto-beams-tp33437479p33437634.html Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \grace after \cadenzaOff suppresses auto-beams

Hello, On 4 March 2012 09:48, -Eluze wrote: > > > David Bobroff wrote: >> >> This is weird.  Maybe known.  I tried to search the issues database but >> did not find anything.  It's possible I don't know how to effectively >> search it. >> >> Here goes; in the following example the auto-beaming is

Re: \grace after \cadenzaOff suppresses auto-beams

; \grace b8 \cadenzaOff \normalsize a4. gis8 e'8 e e e } hth Eluze -- View this message in context: http://old.nabble.com/%5Cgrace-after-%5CcadenzaOff-suppresses-auto-beams-tp33437479p33437558.html Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com. ___

\grace after \cadenzaOff suppresses auto-beams

ithout any music in the cadenza. %%% \version "2.14.2" \relative c' { \time 2/4 c2 \cadenzaOn c2 \teeny d8-[ e f g-] \normalsize \cadenzaOff \bar "|" \normalsize % c2 % uncomment this measure and auto-beaming returns % \autoBeamOn % this will *not* turn bea

Re: Issue 2361 in lilypond: Beams with multiple subdivisions

Comment #1 on issue 2361 by colingh...@gmail.com: Beams with multiple subdivisions http://code.google.com/p/lilypond/issues/detail?id=2361 A typical example provided by David Bobroff Attachments: complex-beam.png 3.1 KB ___ bug-lilypond

Issue 2361 in lilypond: Beams with multiple subdivisions

Status: Accepted Owner: Labels: Type-Enhancement New issue 2361 by colingh...@gmail.com: Beams with multiple subdivisions http://code.google.com/p/lilypond/issues/detail?id=2361 Carl Sorensen posted to request this enhancement to Lilypond: http://lists.gnu.org/archive/html/bug-lilypond

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Status: Verified Comment #13 on issue 2243 by philehol...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 (No comment was entered for this change.) ___ bug-lilypond mailing list

Re: Issue 795 in lilypond: Beams do not take grace notes into account

Updates: Labels: -Patch-needs_work Comment #8 on issue 795 by julien.r...@gmail.com: Beams do not take grace notes into account http://code.google.com/p/lilypond/issues/detail?id=795 (No comment was entered for this change.) ___ bug

Re: Issue 2169 in lilypond: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams

Updates: Labels: -Type-Patch Type-Documentation Comment #7 on issue 2169 by gra...@percival-music.ca: Patch: Doc: Introduce Voices in the correct order. Mention that hideNotes hides beams http://code.google.com/p/lilypond/issues/detail?id=2169 I'm not certain why this was aban

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: -fixed_2_15_60 fixed_2_15_30 Comment #12 on issue 2243 by carl.d.s...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 Typo in version. Thanks for noticing, Colin! Marty (aka Carl

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

On 12-02-09 07:08 PM, lilyp...@googlecode.com wrote: Updates: Status: Fixed Labels: -Patch-push fixed_2_15_60 Comment #11 on issue 2243 by carl.d.s...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 pushed as

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Status: Fixed Labels: -Patch-push fixed_2_15_60 Comment #11 on issue 2243 by carl.d.s...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 pushed as 206f8bfb286a1d67af997ad368ae0326505b95ad Verify with input/regression

Re: Issue 1923 in lilypond: Sketch for broken beams with consistent slopes

Updates: Labels: -Patch-new Comment #2 on issue 1923 by julien.r...@gmail.com: Sketch for broken beams with consistent slopes http://code.google.com/p/lilypond/issues/detail?id=1923 (No comment was entered for this change.) ___ bug

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: -Patch-countdown Patch-push Comment #10 on issue 2243 by colinpkc...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 Counted down to 20120207, please push. ___ bug

Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat

Updates: Status: Verified Comment #15 on issue 2228 by elu...@gmail.com: Some users prefer to minimize partial beams rather than beam by the beat http://code.google.com/p/lilypond/issues/detail?id=2228 (No comment was entered for this change

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: -Patch-new Patch-review Comment #8 on issue 2243 by d...@gnu.org: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 Patchy says LGTM without visible differences. ___ bug-lilypond mailing

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: Patch-new Comment #7 on issue 2243 by carl.d.s...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243#c7 Fix tuplet subdivision (issue 2243) http://codereview.appspot.com/5623051

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: Patch-needs_work Comment #6 on issue 2243 by lilypond...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243#c6 Patchy the autobot says: sorry, same thing: fatal error: define-grob-properties.scm: cannot find interface

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: -Patch-needs_work Patch-new Comment #5 on issue 2243 by gra...@percival-music.ca: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 wait, I forgot to update git to master. Sorry, let me try again

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: Patch-needs_work Comment #4 on issue 2243 by lilypond...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243#c4 Patchy the autobot says: fatal error: define-grob-properties.scm: cannot find interface for property

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Labels: Patch-new Comment #3 on issue 2243 by carl.d.s...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243#c3 Fix tuplet subdivision (issue 2243) http://codereview.appspot.com/5623051

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Updates: Status: Started Owner: carl.d.s...@gmail.com Comment #2 on issue 2243 by carl.d.s...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 I've looked into this. In order to avoid stacking band-aids on band-aids,

Re: Issue 2180 in lilypond: beams are detached from stems

Updates: Status: Verified Comment #20 on issue 2180 by elu...@gmail.com: beams are detached from stems http://code.google.com/p/lilypond/issues/detail?id=2180 ok - verified ___ bug-lilypond mailing list bug-lilypond@gnu.org https

Re: Issue 2180 in lilypond: beams are detached from stems

Comment #19 on issue 2180 by n.putt...@gmail.com: beams are detached from stems http://code.google.com/p/lilypond/issues/detail?id=2180 It's from the fix for issue 2193, which I argued is misguided. Beams shouldn't encompass rests from ot

Re: Issue 2180 in lilypond: beams are detached from stems

Comment #18 on issue 2180 by elu...@gmail.com: beams are detached from stems http://code.google.com/p/lilypond/issues/detail?id=2180 beams are now attached to the corresponding stems - but look at the 2nd quarter of example 1! (no idea if this is caused by or related to this patch

Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat

Comment #14 on issue 2228 by carl.d.s...@gmail.com: Some users prefer to minimize partial beams rather than beam by the beat http://code.google.com/p/lilypond/issues/detail?id=2228 Issue 2244 has been merged into this issue. ___ bug-lilypond

Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat

Updates: Status: Fixed Labels: -Patch-push fixed_2_15_28 Comment #13 on issue 2228 by carl.d.s...@gmail.com: Some users prefer to minimize partial beams rather than beam by the beat http://code.google.com/p/lilypond/issues/detail?id=2228 Pushed as

Re: Issue 2243 in lilypond: Incorrect subdivision of beams

Comment #1 on issue 2243 by m...@apollinemike.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 Tracked this to 44155056614ee1ff6b3bf4f286bdb386147c21a2 via git bisect. Carl - lemme know if you'd like a hand w/ squashing this bug. I have some

Re: Issue 2193 in lilypond: collision between beams and flags

Updates: Status: Verified Comment #21 on issue 2193 by philehol...@gmail.com: collision between beams and flags http://code.google.com/p/lilypond/issues/detail?id=2193 (No comment was entered for this change.) ___ bug-lilypond mailing

Issue 2243 in lilypond: Incorrect subdivision of beams

Status: Accepted Owner: Labels: Type-Critical Regression New issue 2243 by philehol...@gmail.com: Incorrect subdivision of beams http://code.google.com/p/lilypond/issues/detail?id=2243 Reported by Xavier: Just reported on the French Users mailing list: Snippet %% subdivideBeams

Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat

On Thu, Jan 19, 2012 at 06:10:14PM +, Carl Sorensen wrote: > > On 1/19/12 10:05 AM, "Graham Percival" wrote: > > >The proper thing is to: > >- make a branch > >- do a local lsr update maybe better to push right here? > >- make your code and doc change > >- do a local lsr update > > Why is

  1   2   3   4   5   >