Re: Issue 1108 in lilypond: [PATCH]Add independent control of thickness and offset for underline markup (issue1347041)
Updates: Status: Duplicate Mergedinto: 1104 Comment #1 on issue 1108 by brownian.box: [PATCH]Add independent control of thickness and offset for underline markup (issue1347041) http://code.google.com/p/lilypond/issues/detail?id=1108 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1104 in lilypond: Enhancement: 'offset for \underline markup function needed (and proposed)
Comment #3 on issue 1104 by brownian.box: Enhancement: 'offset for \underline markup function needed (and proposed) http://code.google.com/p/lilypond/issues/detail?id=1104 Issue 1108 has been merged into this issue. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1113 in lilypond: score with Ambitus_engraver and voice with spacers only produces programming error
Status: Accepted
Owner:
New issue 1113 by brownian.box: score with Ambitus_engraver and voice with
spacers only produces programming error
http://code.google.com/p/lilypond/issues/detail?id=1113
Reported by David Kastrup:
http://lists.gnu.org/archive/html/bug-lilypond/2010-06/msg00042.html
% sample.ly:
\new Voice \with {\consists Ambitus_engraver} { s4*0 \new Voice { c''4 }
}
% eof
$ LANG=C lilypond sample.ly
GNU LilyPond 2.13.23
Processing `./sample.ly'
Parsing...
./sample.ly:0: warning: no \version statement found, please add
\version 2.13.23
for future compatibility
Interpreting music...
Preprocessing graphical objects...
programming error: note column without heads and stem
continuing, cross fingers
programming error: note-column has no direction
Solving 1 page-breaking chunks...[1: 1 pages]
Drawing systems...
Layout output to `sample.ps'...
Converting to `./sample.pdf'...
success: Compilation successfully completed
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
On Fri 04 Jun 2010, 17:52 David Kastrup wrote:
David Kastrup d...@gnu.org writes:
[...]
\new Voice \with {\consists Ambitus_engraver} { s4*0 \new Voice { c''4 } }
creates the above errors.
Thank you, added as 1113:
http://code.google.com/p/lilypond/issues/detail?id=1113
--
David Kastrup
On Wed 09 Jun 2010, 17:02 Graham Percival wrote:
On Wed, Jun 9, 2010 at 4:55 PM, James Bailey
derhindem...@googlemail.com wrote:
Am I to understand that a programming error should have a bug report?
Yes; current policy is to record all warnings (even false warnings,
which produce good output but include an unexpected error/warning
[...]
_unexpected_
I didn't know that all programming errors should be considered as unexpected
and therefore should be recorded. I'll try to figure out why i didn't.
Cheers,
- Graham
--
Dmytro O. Redchuk
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1113 in lilypond: score with Ambitus_engraver and voice with spacers only produces programming error
Updates: Labels: Type-Defect Priority-Low Warning Comment #1 on issue 1113 by brownian.box: score with Ambitus_engraver and voice with spacers only produces programming error http://code.google.com/p/lilypond/issues/detail?id=1113 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1114 in lilypond: A later note's stem can be to the left of an earlier note's stem
Status: Accepted
Owner:
Labels: Type-Collision Priority-Medium
New issue 1114 by brownian.box: A later note's stem can be to the left of
an earlier note's stem
http://code.google.com/p/lilypond/issues/detail?id=1114
Reported by Richard Sabey:
http://lists.gnu.org/archive/html/lilypond-user/2010-06/msg00140.html
\version 2.13.23
lhMusic =
{
\clef bass
\time 12/4
\repeat unfold 12 {
\stemUp e16 fis! \change Staff = rh
\stemDown g' fis'! \change Staff = lh
}
}
\score
{
\new PianoStaff
\new Staff = rh { s1 s s }
\new Staff = lh \lhMusic
\layout { }
}
\paper { ragged-right = ##t }
Attachments:
sample.png 4.5 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: A later note's stem can be to the left of an earlier note's stem
On Wed 09 Jun 2010, 13:11 Richard Sabey wrote: Occasionally Lilypond decides to fit so many bars into a system that notes are squeezed so tightly together that, in a beamed group, a later note's downward stem can fall to the left of an earlier note's upward stem. The noteheads are in the correct left-to-right order but the stems are in the wrong order. How can I stop Lilypond doing this? I can't predict which bars, if any, Lilypond will decide to squeeze so tightly. %%begin example \version 2.13.17 Thank you, added as Issue 1114 to the tracker: http://code.google.com/p/lilypond/issues/detail?id=1114 -- Dmytro O. Redchuk ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1113 in lilypond: score with Ambitus_engraver and voice with spacers only produces programming error
Comment #2 on issue 1113 by d...@gnu.org: score with Ambitus_engraver and
voice with spacers only produces programming error
http://code.google.com/p/lilypond/issues/detail?id=1113
Please note that the actual reported simplified test case throwing the
error was
\new Voice \with {\consists Ambitus_engraver} { \new Voice { c'' } }
The other given test cases narrow down when the error will occur, and when
not.
The follwing test case still gives an error:
\new Voice \with {\consists Ambitus_engraver} { s4*0 \new Voice { c''4 }
}
while the following two patterns don't:
\new Voice \with {\consists Ambitus_engraver} { s4 \new Voice { c''4 } }
\new Voice \with {\consists Ambitus_engraver} { c4*0 \new Voice { c''4 }
}
and (not explicitly mentioned in the original mail)
\new Voice \with {\consists Ambitus_engraver} { c4 \new Voice { c''4 } }
also does not throw an error.
Like mentioned in the original mail, it would appear that _either_ using up
some time before creating the new voice, _or_ creating an actual note (even
one not using up time) will prevent the errors from occuring.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 995 in lilypond: tuplets at the begin of a piece cannot begin with a \tempo indication
Updates: Status: Accepted Labels: -fixed_2_13_23 Comment #13 on issue 995 by brownian.box: tuplets at the begin of a piece cannot begin with a \tempo indication http://code.google.com/p/lilypond/issues/detail?id=995 Well, since here is no any other opinion (for last 42 hours), i'm adjusting labels. I mean in the current form that piece of documentation is rather _unreadable_, therefore this issue isn't fixed yet. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 684 in lilypond: Enhancement: MetronomeMark should support break-align-symbols
Comment #19 on issue 684 by jordi.na...@gmail.com: Enhancement: MetronomeMark should support break-align-symbols http://code.google.com/p/lilypond/issues/detail?id=684 I still have not tested the patch, but it seems ok. As soon as I can I'll test it. I have one question though, please excuse me if this is not the right place for asking it, how we are supposed to do the payment? Thanks again. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
On Thu, Jun 10, 2010 at 3:23 PM, Graham Percival gra...@percival-music.ca wrote: Focus on processing other old reports that haven't been dealt with yet. I have (sorta) planned to do this as soon as I have a bit more time (several dozen hours are easily required), aka later this month. As for David's bug, it does remind me of something... Perhaps #781? Dmytro: thanks for having added this! Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
On Thu, Jun 10, 2010 at 03:32:46PM +0200, Valentin Villenave wrote: I have (sorta) planned to do this as soon as I have a bit more time (several dozen hours are easily required), aka later this month. If it takes you longer than 10 minutes to process a single email, you're doing something wrong. My initial guess is that you're not rejecting the report when you *should* be rejecting it. I handled over 90% of reports in less than 2 minutes. If the user hasn't said why the output isn't correct, write back to them. You don't need to know anything about Hebrew lyrics or whatever; keep on rejecting the reports until the user writes the third symbol from the left should look like an upside-down rabbit, but it currently looks like a sideways raddish. If you're not familiar with violin parts, force the user to say the upside-down square bucket on the c4\downbow note should be rotated 180 degrees. Whatever. The target is to handle **every** report within **24 hours**. Rejecting is a completely acceptable means of handling it. Look for any excuse you can find to reject the report -- but *find* one, and *write back* to the user. Pretending that you didn't see the email, or letting it rot in your todo folder for 3 months, is *not* an acceptable means of handling it. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
Graham Percival gra...@percival-music.ca writes: PS note that the new email checklist does *not* contain an item for ignore the email and hope that somebody else handles it. If you can't reject the report for having no Tiny example, no version number, not being able to reproduce it, etc., then you MUST move on to the final point, namely adding it to the tracker. I should think that asking for the missing information (with copy on the bug list so that other members of the squad might be aware of the response) should be a valid option as well. For the sake of not eventually getting swamped by leftovers, add it to the tracker would likely be a better choice over make a mental note to ask for more information Real Soon Now (TM). And of course, adding more information is done _automatically_ when someone responds to the tracked report. So adding to the tracker with a canned phrase Small example, and error symptom still missing might well be a safe choice in any case. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this programming error?
On Thu, Jun 10, 2010 at 2:37 PM, David Kastrup d...@gnu.org wrote: Graham Percival gra...@percival-music.ca writes: If you can't reject the report for having no Tiny example, no version number, not being able to reproduce it, etc., then you MUST move on to the final point, namely adding it to the tracker. I should think that asking for the missing information (with copy on the bug list so that other members of the squad might be aware of the response) should be a valid option as well. That's already point 5 on the list: http://kainhofer.com/~lilypond/Documentation/contributor/bug-squad-checklists.html (using kainhofer temporarily because that change isn't in the official docs until 2.13.24) For the sake of not eventually getting swamped by leftovers, add it to the tracker would likely be a better choice over make a mental note to ask for more information Real Soon Now (TM). Yes. And of course, adding more information is done _automatically_ when someone responds to the tracked report. So adding to the tracker with a canned phrase Small example, and error symptom still missing might well be a safe choice in any case. I don't know what you mean by error symptom still missing. If there's a Tiny example and the user explains why the output is incorrect, it goes into the tracker and the Bug Squad should forget about about that issue. They're not programmers, they're not supposed to be programmers. They should ignore that issue until a programmer marks it fixed and the next release is made; at that point, they verify that the fix worked (or not). If there isn't a Tiny example, or if the user didn't clearly explain why the output was bad, or any of the other points in the checklist, then they reject the report. By reject, I mean write back to the user, cc'd to the list, asking for more information. But then it's no longer the responsibility of the Bug Squad; it's the respnosibility of the user to come back with a better example / more info / whatever. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 617 in lilypond: X-offset works in a specific way for RehearsalMarks
Comment #8 on issue 617 by pkx1...@hotmail.com: X-offset works in a
specific way for RehearsalMarks
http://code.google.com/p/lilypond/issues/detail?id=617
Hello, here is the patch for this.
From an email thread from Valentin to me directly:
--8--
The @knwonissues could be something as simple as:
Overriding the #'X-offset property to a fixed value causes the
#'self-alignment-X property to be disregarded. Therefore, it is
recommended to override it with a callback to
ly:self-alignment-interface::x-aligned-on-self, similarly to its
defaut definition. This method is described in @rextend{Callback
functions}.
--8---
Attachments:
0001-Doc-Issue-617-X-offsets-w-Rehearsal-Marks-NR.patch 5.0 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 617 in lilypond: X-offset works in a specific way for RehearsalMarks
Updates: Status: Fixed Labels: fixed_2_13_24 Comment #9 on issue 617 by percival.music.ca: X-offset works in a specific way for RehearsalMarks http://code.google.com/p/lilypond/issues/detail?id=617 Thanks, pushed. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 815 in lilypond: Enhancement: AJAX-powered search auto-completion for the online documentation
Updates: Status: Verified Comment #10 on issue 815 by percival.music.ca: Enhancement: AJAX-powered search auto-completion for the online documentation http://code.google.com/p/lilypond/issues/detail?id=815 Verified, and visible on kainhofer, for example here: http://kainhofer.com/~lilypond/Documentation/notation/index.html ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1073 in lilypond: convert-ly and accented characters
Updates: Labels: abandoned_patch Comment #2 on issue 1073 by percival.music.ca: convert-ly and accented characters http://code.google.com/p/lilypond/issues/detail?id=1073 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1029 in lilypond: \thumb should behave like other fingerings
Updates: Status: Fixed Labels: fixed_2_13_24 Comment #7 on issue 1029 by n.puttock: \thumb should behave like other fingerings http://code.google.com/p/lilypond/issues/detail?id=1029 Thanks for the patch, Frédéric. It's applied. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 617 in lilypond: X-offset works in a specific way for RehearsalMarks
Comment #12 on issue 617 by n.puttock: X-offset works in a specific way for RehearsalMarks http://code.google.com/p/lilypond/issues/detail?id=617 I was hoping James's patch would sit there for a while longer (at least until I had chance to review it. :) I still think the best option is to follow my advice in comment #3. Users shouldn't be overriding X-offset unless they're familiar with the IR and the consequences of removing the default callback. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tie positioning in chords with large intervals [engraving-nitpick?]
On 2010-06-07 18:07, Phil Holmes wrote:
Looks like this hasn't been progressed. Should it be raised as a bug?
Since nobody else seems to answer: Yes please, as far as I'm concerned.
Engraving-nitpick seems the right category to me, it's certainly a minor
issue.
[from another message]
(yes - I am working my way through .bugs for likely outstanding issues.)
While you're at it: Could you have a look at this one on -devel, too?
http://www.mail-archive.com/lilypond-de...@gnu.org/msg29267.html
It's been pinged just a few days ago, but it looks like is falling into
oblivion once again. Probably because it's hard to specify the desired
behaviour really well, but I think Kieren made a good effort in
http://lists.gnu.org/archive/html/lilypond-user/2008-06/msg00591.html.
Alexander Kobel n...@a-kobel.de wrote in message
news:4b570f21.3070...@a-kobel.de...
Hi, all,
in the attached example the tie positioning is not quite what I'd expect
to be the favourite option (on 2.13.11).
It's about chords with large intervals in between, where the tie can be
fitted into the space between note heads. This looks strange when the
inner ties exceed the range of the outer ties of the chord.
For stem-up chords, a simple workaround is adding transparent notes to
the chord, to block the empty space in between. For stem-down chords,
I'd prefer the tie (between the c'') to be a mirrored version of the
bottom tie (between the a'), i.e. attached to the center of the left
note head instead of either the left or the right side of it; this I
could not achieve with an additional note.
Would it be sensible to crop the range of interior ties to the union of
the extents of the outer ties in general?
Cheers,
Alexander
\relative c'' {
g d g,4~ g d g,
g d b g4~ g d b g
g d g,4~ g d b g
g d g,4~ g d \tweak #'transparent ##t b g
a' c, a4~ a c, a
a e c a4~ a e c a
a e c a4~ a c, a
a \tweak #'transparent ##t e c a4~ a c, a
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 382 in lilypond: misaligned nested \fill-lines
Updates: Status: Started Owner: n.puttock Comment #1 on issue 382 by n.puttock: misaligned nested \fill-lines http://code.google.com/p/lilypond/issues/detail?id=382 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 617 in lilypond: X-offset works in a specific way for RehearsalMarks
Comment #10 on issue 617 by n.puttock: X-offset works in a specific way for
RehearsalMarks
http://code.google.com/p/lilypond/issues/detail?id=617
--8--
The @knownissues could be something as simple as:
Overriding the #'X-offset property to a fixed value causes the
#'self-alignment-X property to be disregarded. Therefore, it is
recommended to override it with a callback to
ly:self-alignment-interface::x-aligned-on-self, similarly to its
defaut definition. This method is described in @rextend{Callback
functions}.
--8---
This is not recommended at all. The default callback is a closure,
combining the result of ly:self-alignment-interface:x-aligned-on-self *and*
ly:break-alignable-interface::self-align-callback. Thus overriding
X-offset also causes 'break-align-symbols to be ignored, messing up the
positioning completely.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 915 in lilypond: Multi-measure rests dependent on prefatory matter in other staves
Comment #9 on issue 915 by n.puttock: Multi-measure rests dependent on prefatory matter in other staves http://code.google.com/p/lilypond/issues/detail?id=915 Patch updated to use symbols in 'spacing-pair (allows finer control over rest positioning.) http://codereview.appspot.com/931041/show ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 617 in lilypond: X-offset works in a specific way for RehearsalMarks
Updates: Status: Accepted Labels: -fixed_2_13_24 Comment #11 on issue 617 by percival.music.ca: X-offset works in a specific way for RehearsalMarks http://code.google.com/p/lilypond/issues/detail?id=617 ok, I've reverted the patch. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
