On Mon, 2009-01-12 at 03:37 +0100, Valentin Villenave wrote:
> 2009/1/12 Joe Neeman :
>
> > BTW Valentin, I think the appropriate response here would be to remove
> > the "Fixed" label. "Fixed," to me, means "I think I've fixed it, can
> > someone please check." If the status is left as Fixed, I p
2009/1/12 Joe Neeman :
> BTW Valentin, I think the appropriate response here would be to remove
> the "Fixed" label. "Fixed," to me, means "I think I've fixed it, can
> someone please check." If the status is left as Fixed, I probably won't
> look at the bug when I'm next browsing the bug list.
Y
On Sun, 2009-01-11 at 17:04 -0800, Mark Polesky wrote:
> Valentin Villenave wrote:
>
> > 2009/1/12 Mark Polesky :
> >
> > > I don't consider this issue "fixed".
> >
> > Mark, I've added your comment and your example. However, do keep in
> > mind that the status for closed issues is "verified", n
Updates:
Status: Accepted
Labels: -fixed_2_12_2
Comment #5 on issue 726 by joeneeman: Request: accidentals in the same
octave would look better not aligned (in some cases)
http://code.google.com/p/lilypond/issues/detail?id=726
(No comment was entered for this change.)
--
You
Valentin Villenave wrote:
> 2009/1/12 Mark Polesky :
>
> > I don't consider this issue "fixed".
>
> Mark, I've added your comment and your example. However, do keep in
> mind that the status for closed issues is "verified", not "fixed", and
> this is not "verified" yet.
>
> Another comment: ple
Updates:
Summary: Request: accidentals in the same octave would look better not
aligned (in some cases)
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Comment #4 on issue 726 by v.villenave: Request: accidentals in the same
octave would look better not aligned (
2009/1/12 Mark Polesky :
> I don't consider this issue "fixed".
Mark, I've added your comment and your example. However, do keep in
mind that the status for closed issues is "verified", not "fixed", and
this is not "verified" yet.
Another comment: please use extra diplomacy (and patience) whenev
Comment #3 on issue 726 by v.villenave: Wrong accidentals alignment when a
second occurs simultaneously
http://code.google.com/p/lilypond/issues/detail?id=726
Hmm. Looks a bit funny though; are we sure we want to keep this rule?
New comment from Mark:
Ted Ross (pp.130-135) demonstrates that
> Comment #2 on issue 726 by joeneeman: Wrong accidentals alignment when a
> second occurs simultaneously
> http://code.google.com/p/lilypond/issues/detail?id=726
>
> The behaviour for the first example is explained by the fact that we align
> accidentals belonging to the same octave.
But that
Updates:
Status: Fixed
Labels: fixed_2_12_2
Comment #2 on issue 726 by joeneeman: Wrong accidentals alignment when a
second occurs simultaneously
http://code.google.com/p/lilypond/issues/detail?id=726
The behaviour for the first example is explained by the fact that we align
a
Updates:
Labels: -Type-Enhancement Type-Defect
Comment #1 on issue 724 by v.villenave: Staves that begin with an
accidental should have more space before their first note.
http://code.google.com/p/lilypond/issues/detail?id=724
an additional comment from Mark:
"By far the most authorit
> New issue 724 by v.villenave: Staves that begin with an accidental should
> have more space before their first note.
> http://code.google.com/p/lilypond/issues/detail?id=724
By far the most authoritative information on this
topic is Ted Ross, The Art of Music Engraving and
Processing, pp.143
Updates:
Status: Fixed
Comment #3 on issue 722 by lemzwerg: newline inside @macro{} in texinfo
screws up
http://code.google.com/p/lilypond/issues/detail?id=722
(No comment was entered for this change.)
--
You received this message because you are listed in the owner
or CC fields of t
2008/12/11 Trevor Daniels :
>
> Graham Breed wrote Thursday, December 11, 2008 1:01 AM
>
>
>> I can demonstrate the bug with that file though. Here's an example:
>>
>> \version "2.11.65"
>> \include "arabic.ly"
>>
>> melody = \relative {
>> \key re \bayati
>> do re mi fa sol la si do
>> }
>>
>>
2008/12/12 Trevor Daniels :
>> A patch is on its way. :)
>
> Great! In which case I'll leave the docs as they are for now. When this is
> fixed I'll have a look at expanding the section which covers non-standard
> key signatures.
Added as http://code.google.com/p/lilypond/issues/detail?id=733
Status: Started
Owner: v.villenave
Labels: Type-Defect Priority-Medium
New issue 733 by v.villenave: Non-standard octave-limited key signature
does not persist
http://code.google.com/p/lilypond/issues/detail?id=733
Report from Trevor D:
If a non-standard key signature is defined using the fo
2009/1/11 Graham Percival :
> The idea is simply to avoid the evilness of personal TODO lists:
> unless you're certain that you'll handle something within two
> weeks, add it to the tracker so it doesn't get lost. I don't
> anticipate a huge number of Type-Other items.
OK.
Cheers,
Valentin
__
2008/12/7 Mark Polesky :
> NR 1.7.1 "Editorial annotations: Inside the staff"
> (strangely) contains the info on stems directions.
It makes sense to me (strangely).
> How are stem directions related to editorial annotations?
> I think the Stem entry would be better placed either in
> 1.2 "Rhythms
2008/12/4 Dana S Emery :
> I submit this as a bug report because I didnt see any better way to bring the
> matter to attention.
Greetings and thank you for your contribution (with much delay).
We have precisely entered a major rewriting/redesigning process of our
website, to it is the right time
On Sun, Jan 11, 2009 at 06:48:49AM -0700, Carl D. Sorensen wrote:
>
> On 1/11/09 6:26 AM, "Valentin Villenave" wrote:
>
> > While I wouldn't take the risk to correct this myself, i'm sure one of
> > our Frog could happily fix it :-)
> > http://code.google.com/p/lilypond/issues/detail?id=729
>
>
Updates:
Summary: Simultaneous simple expressions affected to a same Staff collide
by default.
Status: Accepted
Owner: v.villenave
Labels: Type-Enhancement Priority-Medium
Comment #2 on issue 709 by v.villenave: Simultaneous simple expressions
affected to a same Staf
2008/12/11 Reinhold Kainhofer :
> I have now found a nice workaround for my problems with the center-column-
> markup: Simply wrap a left-column-markup around to offset the shifted
> reference point...
I can't say I've been following this whole affair quite thoroughly,
but I've added the bits I u
Status: Started
Owner: v.villenave
CC: reinhold.kainhofer
Labels: Type-Defect Priority-Medium
New issue 732 by v.villenave: Alignment problems when vertically stacking
horizontally centered stencils.
http://code.google.com/p/lilypond/issues/detail?id=732
% In the following example:
\version
Greetings,
when trying to convert-ly -e the following snippet
\version "2.11.0"
\markup { \hcenter{ here I am} }
(which isn't illegal code IMNSHO)
the deprecated \hcenter command is not updated.
Bug or feature?
Cheers,
Valentin
___
bug-lilypond ma
2008/11/24 Neil Puttock :
> The Bar_number_engraver can't see the top stave, since the
> Staff_collecting_engraver has been moved to the Staff context
> (stavesFound will return an empty list).
What's with this engraver anyway? do we really have to move it? (I
have done so in my opera, and since
On 1/11/09 6:26 AM, "Valentin Villenave" wrote:
> 2008/11/20 Mats Bengtsson :
>
>> It's easy to fix in LilyPond, but we shouldn't forget to add a convert-ly
>> rule for it.
>
> While I wouldn't take the risk to correct this myself, i'm sure one of
> our Frog could happily fix it :-)
> http:/
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Low
New issue 731 by v.villenave: \break can not be used together with \grace
in proportional notation.
http://code.google.com/p/lilypond/issues/detail?id=731
From the "grace notes are a PITA" series:
Victor Adán noticed that t
2008/11/21 Trevor Bača :
> Yes, so this is still a bug: we need to be able to have "break graces"
> together with strict note, proportional spacing. (FWIW, strict-note-spacing
> is always supposed to accompany proportionalNotation; ie, when we turn on
> proportionalNotation, we're always supposed
Status: Accepted
Owner: v.villenave
Labels: Type-Enhancement Priority-Medium
New issue 730 by v.villenave: AccidentalPlacement should take 'left-padding
into account
http://code.google.com/p/lilypond/issues/detail?id=730
Report from Mark:
\version "2.11.64-1"
\relative {
%% right-padding i
2008/11/20 Mats Bengtsson :
> Yes! I reported this back in
> http://lists.gnu.org/archive/html/lilypond-user/2008-01/msg00297.html
> but it seems that it never made it to the bug tracker.
Well, this time I'm not letting it go.
http://code.google.com/p/lilypond/issues/detail?id=730
Cheers,
Valenti
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Medium
New issue 729 by v.villenave: MIDI #47 instrument's name is incorrect
http://code.google.com/p/lilypond/issues/detail?id=729
Report from Francisco Gonzalez:
LilyPond's #47 MIDI instrument is named is "orchestral strings"; a
2008/11/20 Mats Bengtsson :
> It's easy to fix in LilyPond, but we shouldn't forget to add a convert-ly
> rule for it.
While I wouldn't take the risk to correct this myself, i'm sure one of
our Frog could happily fix it :-)
http://code.google.com/p/lilypond/issues/detail?id=729
Cheers,
Valentin
Updates:
Summary: Wrong accidentals alignment when a second occurs simultaneously
Cc: joeneeman
Comment #1 on issue 726 by v.villenave: Wrong accidentals alignment when a
second occurs simultaneously
http://code.google.com/p/lilypond/issues/detail?id=726
A related example from
2008/11/14 Brian Mearns :
> I've noticed this bug has been reported for various other versions, but
> haven't
> seen it for 2.11 yet. Every time I run lilypond, it has to rebuild the
> font-cache, and ends up touching
> ~/.lilypond-fonts.cache-2/ef9c9ad8cc5857eb63cb3660bc8bd202-i686-mingw32.cache-
2008/11/9 Mark Polesky :
> accidental shifts left as it nears a 2nd (interval):
Added as a comment to
http://code.google.com/p/lilypond/issues/detail?id=726
(seems obviously related)
Cheers,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
Status: Accepted
Owner: v.villenave
Labels: Type-Collision Priority-Medium
New issue 728 by v.villenave: Fingerings collide with accidentals.
http://code.google.com/p/lilypond/issues/detail?id=728
% Some accidentals may collide with fingerings.
% Comments follow (thanks to Trevor D):
\version "
2008/11/11 Trevor Daniels :
> This accidental/fingering collision appears to be a bug, so I'm copying to
> the bug list. I can't find a similar bug in the bug DB.
Thanks to both of you; added (with much delay) as
http://code.google.com/p/lilypond/issues/detail?id=728
Cheers,
Valentin
_
Comment #1 on issue 570 by v.villenave: Articulations can collide with ties
http://code.google.com/p/lilypond/issues/detail?id=570
New example from James Bailey:
{
c'''2~ c'''8\fermata r8 r4
}
% the fermata collides with the tie.
--
You received this message because you are listed in the ow
Updates:
Summary: convert-ly fails to convert keySignature
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Maintainability
Comment #1 on issue 708 by v.villenave: convert-ly fails to convert
keySignature
http://code.google.com/p/lilypond/issues/detail?id
Comment #2 on issue 722 by lemzwerg: newline inside @macro{} in texinfo
screws up
http://code.google.com/p/lilypond/issues/detail?id=722
The problem is not that a macro spans more than a single line -- this is
handled
just fine. The very problem is that @rlearning and friends contain a cal
2008/11/9 Mark Polesky :
> pedal glyphs top-aligned instead of bottom-aligned:
Thanks, added as
http://code.google.com/p/lilypond/issues/detail?id=727
Would you have a real-world example? In all my scores, the "*" glyph
is always printed all over the place without any consistency.
Carl, could th
Status: Accepted
Owner: v.villenave
Labels: Type-Enhancement Priority-Low
New issue 727 by v.villenave: Pedal "*" glyph should be bottom-aligned
http://code.google.com/p/lilypond/issues/detail?id=727
% See attached picture.
\version "2.12.1"
\relative {
c'\sustainOn^\markup default
c\sustain
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Medium
New issue 726 by v.villenave: Wrong accidentals alignment when a second
occurs in another voice
http://code.google.com/p/lilypond/issues/detail?id=726
% In the following example, the highest note is correctly printed in t
2008/11/9 Mark Polesky :
> Improper alignment of two accidentals in the presence
> of a 2nd (interval):
Thanks, added (with a simpler example) as
http://code.google.com/p/lilypond/issues/detail?id=726
Cheers,
Valentin
___
bug-lilypond mailing list
bug
2008/11/9 Mark Polesky :
> "p" and "f" dynamic glyphs align differently:
Thanks, added as
http://code.google.com/p/lilypond/issues/detail?id=725
Though I don't know what I'm talking about, could that be a kerning
problem with the "f" (in other words, is it normal that the f takes so
much horizont
Status: Accepted
Owner: v.villenave
Labels: Type-Enhancement Priority-Low Engraving-nitpick
New issue 725 by v.villenave: "p" and "f" dynamics should be aligned in the
same way
http://code.google.com/p/lilypond/issues/detail?id=725
% Report from Mark:
% "p" and "f" dynamic glyphs align differ
2008/11/9 Mark Polesky :
> not enough space after prefatory matter if
> accidental comes first:
Thanks, (finally) added as
http://code.google.com/p/lilypond/issues/detail?id=724
Cheers,
Valentin
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http:
Status: Accepted
Owner: v.villenave
Labels: Type-Enhancement Priority-Postponed Engraving-nitpick
New issue 724 by v.villenave: Staves that begin with an accidental should
have more space before their first note.
http://code.google.com/p/lilypond/issues/detail?id=724
% Report from Mark:
% Wh
Status: Accepted
Owner: v.villenave
Labels: Type-Defect Priority-Low Engraving-nitpick
New issue 723 by v.villenave: wrong horizontal alignement of pedal brackets
with a second inside a chord
http://code.google.com/p/lilypond/issues/detail?id=723
% If you have a chord where one note is printe
2008/11/5 Francisco Vila :
> I can reproduce this on 2.11.63. Looks like a bug. I can not found it
> as an existing one in tracker.
Thanks, added (with much delay) as
http://code.google.com/p/lilypond/issues/detail?id=723
Cheers,
Valentin
___
bug-lil
On Sun, Jan 11, 2009 at 12:10:49PM +, codesite-nore...@google.com wrote:
>
> Comment #1 on issue 722 by v.villenave: newline inside @macro{} in
> texinfo screws up
> http://code.google.com/p/lilypond/issues/detail?id=722
>
> Perhaps we could have a dedicated Type label for such bugs, such as
Comment #1 on issue 722 by v.villenave: newline inside @macro{} in texinfo
screws up
http://code.google.com/p/lilypond/issues/detail?id=722
Perhaps we could have a dedicated Type label for such bugs, such
as "Type-Docbug"?
--
You received this message because you are listed in the owner
o
52 matches
Mail list logo
