Issue 1418 in lilypond: regtests "cells:" field isn't documented

Status: Accepted Owner: Labels: Type-Documentation Maintainability Priority-Medium New issue 1418 by v.villenave: regtests "cells:" field isn't documented http://code.google.com/p/lilypond/issues/detail?id=1418 http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00320.html _

Issue 1417 in lilypond: regtests "time" field is broken

Status: Accepted Owner: Labels: Type-Defect Maintainability Priority-Medium New issue 1417 by v.villenave: regtests "time" field is broken http://code.google.com/p/lilypond/issues/detail?id=1417 http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg00320.html _

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Sat, Nov 20, 2010 at 01:02:25AM +0100, Valentin Villenave wrote: > On Sat, Nov 20, 2010 at 12:33 AM, Graham Percival > wrote: > > If you want to improve our speed, then look into the "time" fields > > in the regtest comparison.  It appears to be currently broken, but > > fixing this will likely

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Sat, Nov 20, 2010 at 12:33 AM, Graham Percival wrote: > Correctness is more important than speed. Only within reasonable limits. > If you want to improve our speed, then look into the "time" fields > in the regtest comparison.  It appears to be currently broken, but > fixing this will likely

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Fri, Nov 19, 2010 at 11:33:23PM +, Graham Percival wrote: > On Sat, Nov 20, 2010 at 12:17:55AM +0100, Valentin Villenave wrote: > > (Or possibly open a new issue about it; we should also consider > > making it a High-prio, since I doubt we want to release a new > > stable version with that m

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Sat, Nov 20, 2010 at 12:17:55AM +0100, Valentin Villenave wrote: > On Fri, Nov 19, 2010 at 11:25 PM, wrote: > > Unfortunately there's been a drop in performance since 2.13.36; I've > > narrowed it down to Joe's fix for issue 1240 (5266aa). > > That's annoying. ... > Should I reopen #1240?

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

On Fri, Nov 19, 2010 at 11:25 PM, wrote: > Unfortunately there's been a drop in performance since 2.13.36; I've > narrowed it down to Joe's fix for issue 1240 (5266aa). As you can see from > the above timings, it adds over forty minutes to both optimized and standard > builds. That's annoying.

Re: Issue 1211 in lilypond: [PATCH]Optimizations for pure-height approximations. (issue1817045)

Comment #4 on issue 1211 by n.puttock: [PATCH]Optimizations for pure-height approximations. (issue1817045) http://code.google.com/p/lilypond/issues/detail?id=1211 I've done some more benchmarking, this time using Valentin's opera* (which annoyingly, I still haven't succeeded in compiling in

Re: imperfect convert-ly rules

On 19 November 2010 02:24, Keith E OHara wrote: > Now I see the value in a non-naive conversion that would produce something > like : >  between-system-padding = 5\mm >  system-system-spacing #'padding = #(/ between-system-padding staff-space) I like this. :) I was thinking of all sorts of conv

Re: imperfect convert-ly rules

On 18 November 2010 22:15, Keith E OHara wrote: > But I *like* being naive, Neil. :) > The ugly truth is the units for vertical spacing changed from mm to staff > spaces.  The current convert-ly rule also fails to convert to the new units, > in cases where units are not specified, which is the

Re: Issue 1415 in lilypond: [PATCH] Clef support for cue notes (issue2726043)

Updates: Status: Started Owner: reinhold.kainhofer Labels: Priority-High Comment #1 on issue 1415 by n.puttock: [PATCH] Clef support for cue notes (issue2726043) http://code.google.com/p/lilypond/issues/detail?id=1415 (No comment was entered for this change.) ___

Re: Issue 1414 in lilypond: [PATCH]Allow music identifiers in \addlyrics (no need for braces any more)(Issue2740044)

Updates: Status: Started Owner: reinhold.kainhofer Labels: Priority-High Comment #1 on issue 1414 by n.puttock: [PATCH]Allow music identifiers in \addlyrics (no need for braces any more)(Issue2740044) http://code.google.com/p/lilypond/issues/detail?id=1414 (No comment

Re: Issue 1416 in lilypond: Point-and-click URIs for embedded LilyPond expressions are malformed

Comment #1 on issue 1416 by n.puttock: Point-and-click URIs for embedded LilyPond expressions are malformed http://code.google.com/p/lilypond/issues/detail?id=1416 You'll also get the same problem (with a slightly different URI, string>) when using ly:parser-include-string: #(ly:parser-incl

Issue 1416 in lilypond: Point-and-click URIs for embedded LilyPond expressions are malformed

Status: Accepted Owner: Labels: Type-Defect Priority-Low New issue 1416 by pnorcks: Point-and-click URIs for embedded LilyPond expressions are malformed http://code.google.com/p/lilypond/issues/detail?id=1416 Original report: http://lists.gnu.org/archive/html/bug-lilypond/2010-11/msg0025

Re: Point-and-Click URIs not properly formed (see text at end of message)

On Fri, Nov 19, 2010 at 8:56 AM, Mike Bagneski wrote: > I should explain that the .ly files that cause this are exported from > Tuxguitar, so my understanding of lilypond code is limited.  Here's a much > smaller example that returns the busted URIs: > > TrackAVoiceAMusic = #(define-music-function

Re: Issue 146 in lilypond: bar counters for normal bars

On 2010-11-19 18:17, Valentin Villenave wrote: On Fri, Nov 19, 2010 at 3:48 PM, Alexander Kobel wrote: (Note this is what I feel bar counters should look like, and it's similar to what Werner implemented in the much simpler . For a proper enhancement, w

Re: Issue 146 in lilypond: bar counters for normal bars

On Fri, Nov 19, 2010 at 3:48 PM, Alexander Kobel wrote: > (Note this is what I feel bar counters should look like, and it's similar to > what Werner implemented in the much simpler > .  For a proper enhancement, we > should have a look in some notation guid

Re: Issue 146 in lilypond: bar counters for normal bars

"Alexander Kobel" wrote in message news:4ce68e48.5070...@a-kobel.de... On 2010-11-19 15:37, Phil Holmes wrote: wrote in message Comment #5 on issue 146 by lemzwerg: bar counters for normal bars http://code.google.com/p/lilypond/issues/detail?id=146 It's simply not implemented yet. Someone ha

Re: Issue 146 in lilypond: bar counters for normal bars

On 2010-11-19 15:37, Phil Holmes wrote: wrote in message Comment #5 on issue 146 by lemzwerg: bar counters for normal bars http://code.google.com/p/lilypond/issues/detail?id=146 It's simply not implemented yet. Someone has to add a RepeatCounter grob (in analogy to PercentRepeatCounter). I'm

Re: Issue 146 in lilypond: bar counters for normal bars

wrote in message news:5-9567054385019064696-4879371268457720840-lilypond=googlecode@googlecode.com... Comment #5 on issue 146 by lemzwerg: bar counters for normal bars http://code.google.com/p/lilypond/issues/detail?id=146 It's simply not implemented yet. Someone has to add a RepeatCounte

Re: Issue 146 in lilypond: bar counters for normal bars

Comment #5 on issue 146 by lemzwerg: bar counters for normal bars http://code.google.com/p/lilypond/issues/detail?id=146 It's simply not implemented yet. Someone has to add a RepeatCounter grob (in analogy to PercentRepeatCounter). ___ bug-lilypo

Re: Issue 146 in lilypond: bar counters for normal bars

Comment #4 on issue 146 by PhilEHolmes: bar counters for normal bars http://code.google.com/p/lilypond/issues/detail?id=146 How is adding bar counters different from having the measure numbers that LilyPond currently supports? ___ bug-lilypond mai

Re: Issue 37 in lilypond: collision notehead and beams

Comment #4 on issue 37 by PhilEHolmes: collision notehead and beams http://code.google.com/p/lilypond/issues/detail?id=37 Get the same problem even with explicit voice naming and simpler music: \new Staff \relative c'' { << \new Voice { \voiceOne s16 c16[ s c] } \new Voice { \voiceTwo b'16[

Issue 1415 in lilypond: [PATCH] Clef support for cue notes (issue2726043)

Status: New Owner: Labels: Type-Enhancement Patch New issue 1415 by neziap: [PATCH] Clef support for cue notes (issue2726043) http://code.google.com/p/lilypond/issues/detail?id=1415 http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00642.html http://codereview.appspot.com/2726043/

Re: Issue 621 in lilypond: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)

Comment #1 on issue 621 by PhilEHolmes: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc) http://code.google.com/p/lilypond/issues/detail?id=621 Image added Attachments: 621.png 3.6 KB ___ bug-lilypond mailing

Issue 1414 in lilypond: [PATCH]Allow music identifiers in \addlyrics (no need for braces any more)(Issue2740044)

Status: New Owner: Labels: Type-Enhancement Patch New issue 1414 by neziap: [PATCH]Allow music identifiers in \addlyrics (no need for braces any more)(Issue2740044) http://code.google.com/p/lilypond/issues/detail?id=1414 http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00597.h

Re: Issue 1298 in lilypond: minimum-Y-extent might be obsolete?

Updates: Labels: Patch Comment #15 on issue 1298 by v.villenave: minimum-Y-extent might be obsolete? http://code.google.com/p/lilypond/issues/detail?id=1298 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypo

Re: Issue 139 in lilypond: tie misinterpreted as a slur

Updates: Labels: -Priority-Low Priority-High Comment #12 on issue 139 by PhilEHolmes: tie misinterpreted as a slur http://code.google.com/p/lilypond/issues/detail?id=139 Another example where there should be one tied note within a chord, but LilyPond typesets it as if it's a slur, whic