Re: Issue 1701 in lilypond: default accidental style prints too many 'extra' naturals
bruys . notenoir at gmail.com writes: I came across a further reference, in Richard Rastall's The Notation of Western Music (2nd edition), I can look at that during my next trip to the closest university. I did look through Bach's manuscript Well-tempered Clavier, noticed that a natural alone sufficed (in 1722) to convert gisis to gis (BWV 853) but could not find any single sharps following single flats (unsurprisingly). If we go forward in time to Chopin, we find lots of varied accidentals. Editor Carl Mikuli (1819 — 1897) almost always puts the natural to cancel a double-flat, but never writes a natural to cancel a single-flat before a sharped note. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1502 in lilypond: Document information in PDF headers requires escapes for accented characters
Updates: Status: Verified Comment #9 on issue 1502 by philehol...@googlemail.com: Document information in PDF headers requires escapes for accented characters http://code.google.com/p/lilypond/issues/detail?id=1502 Thanks for this, Keith. Took me a while to research the fact that the problem was only with the properties, not the output itself. But I'm pleased to say that both display properly on Windows on 2.15.2 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1685 in lilypond: links to spanish changes manual
Updates: Status: Fixed Labels: fixed_2_15_3 backport Comment #4 on issue 1685 by percival.music.ca: links to spanish changes manual http://code.google.com/p/lilypond/issues/detail?id=1685 Looks fine, pushed. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1705 in lilypond: New breve rest with ledger lines
Status: Accepted Owner: Labels: Type-Enhancement Priority-Medium Patch-review New issue 1705 by percival.music.ca: New breve rest with ledger lines http://code.google.com/p/lilypond/issues/detail?id=1705 http://codereview.appspot.com/4650052/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1701 in lilypond: default accidental style prints too many 'extra' naturals
Comment #8 on issue 1701 by percival.music.ca: default accidental style prints too many 'extra' naturals http://code.google.com/p/lilypond/issues/detail?id=1701 In light of the discussion about this patch, how hard would it be to make it controllable? I don't have a good idea of the name, since IIRC we already have an extraNatural property. If the existing properties already let users get the old behaviour, then go ahead and push now. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 163 in lilypond: huge (ugly) slur (both phrasing and normal)
On Wed, Jun 22, 2011 at 06:52:43PM -0600, Colin Campbell wrote:
On 11-06-22 05:47 AM, Dmytro O. Redchuk wrote:
I would start with this:
Looks great; Colin, could you add that to the CG in the Issues
chapter?
Do we need more options? For trimming in place or something else?
I don't think so. As long as it's clear that the bug squad should
uploade the bug-trim.png file, that's fine.
After a bit of testing, it seems that settings in \included files,
however the include is done (very smooth trick, that, David!), are
overridden if the tag exists in the destination file.
So if you run the script on
\header { tagline=foo }
\relative c' { c4}
you'll still get a tagline? IMO that's an (accidental) feature,
not a bug! Most bug reports are short and don't have a tagline
defined, so you want to trim the existing one. If a bug report
explicitly adds a tagline=abcd, then it would be good to not
trim that one. (if the tagline= is not relevant to the bug, then
the bug report should be rejected because it's not Tiny)
Where a .ly file already has the tagline set, it cancels the
imported one. To do this from a script will, after all, take
some sed or perhaps python magic. I'll keep at it, as much for
education as for the satisfaction!
Well, go ahead for your own satisfaction, but I'd reject any patch
that changes the script to do this. :)
Cheers,
- Graham
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1706 in lilypond: Beaming causes lilypond to crash
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical Regression
New issue 1706 by philehol...@googlemail.com: Beaming causes lilypond to
crash
http://code.google.com/p/lilypond/issues/detail?id=1706
Reported by Stefan Thomas:
the following code works fine in 2.12.3. but doesn't in 2.14.1.
Is there a possibility to get it working in 2.14.1?
\version 2.14.1
music = {
\clef bass r2 r4 r8 f,
r2 r4 g,8 r
r4 f, 8 r8 r2
}
beams = {
\repeat unfold 24 { s8[ s ] s[ s]} % this line causes the error!
}
\new Staff {
\context Voice { \beams } { \music}
}
His doesn't work should be read as causes LilyPond to crash. Marking
this as critical, because even though it seems slightly odd code to me, we
shouldn't respond by crashing LilyPond. Error messages include:
file.ly:10:33: programming error: must have Item for spanner bound of Beam
\repeat unfold 24 { s8[ s ] s
[ s]} % this line causes the error!
Preprocessing graphical objects...
programming error: Grob direction requested while calculation in progress.
continuing, cross fingers
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1701 in lilypond: default accidental style prints too many 'extra' naturals
lilyp...@googlecode.com writes: Comment #8 on issue 1701 by percival.music.ca: default accidental style prints too many 'extra' naturals http://code.google.com/p/lilypond/issues/detail?id=1701 In light of the discussion about this patch, how hard would it be to make it controllable? I don't have a good idea of the name, since IIRC we already have an extraNatural property. If the existing properties already let users get the old behaviour, then go ahead and push now. As long as not a single user _wants_ the old behavior, why bother? -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1701 in lilypond: default accidental style prints too many 'extra' naturals
On Thu, Jun 23, 2011 at 02:40:08PM +0200, David Kastrup wrote: lilyp...@googlecode.com writes: In light of the discussion about this patch, how hard would it be to make it controllable? I don't have a good idea of the name, since IIRC we already have an extraNatural property. As long as not a single user _wants_ the old behavior, why bother? I thought that some people _did_ want that behavior. There is some discussion about whether or not they _should_ want that behavior, but if it's easy to accommodate them, I'd rather that lilypond allow people to shoot themselves in the foot if they specifically request it. That said, since this only changes something in scheme, presumably any user could redefine that function in their .ly file, thereby getting the old (possibly ridiculously bad) behavior? If so, then I have no objection to pushing the change now. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 163 in lilypond: huge (ugly) slur (both phrasing and normal)
On Thu, Jun 23, 2011 at 06:48:47AM -0600, Colin Campbell wrote:
On 11-06-23 05:46 AM, Graham Percival wrote:
On Wed, Jun 22, 2011 at 06:52:43PM -0600, Colin Campbell wrote:
On 11-06-22 05:47 AM, Dmytro O. Redchuk wrote:
I would start with this:
Looks great; Colin, could you add that to the CG in the Issues
chapter?
That's Dmytro's script, Graham! My bash-fu is still at an early stage.
Ah, sorry, my punctuation was too confusing.
Dmytro: looks great.
Colin: add this to the CG (since Dmytro isn't trained in making
patches).
Most bug reports are short and don't have a tagline
defined, so you want to trim the existing one. If a bug report
explicitly adds a tagline=abcd, then it would be good to not
trim that one. (if the tagline= is not relevant to the bug, then
the bug report should be rejected because it's not Tiny)
A problem arises when, as I suspect, the default behaviour is
tagline = ##t, even when not explicitly stated in the \header block.
IOW, the absence of tagline = doesn't mean absence of a tagline.
The presence of the tagline means convert must include the entire
page in the trimmed area, which defeats the purpose of the trim.
I suspect that you're confusing yourself, or at least certainly
me? The script produces a small png for:
\relative c' { c4 }
That's what we want. Do you see a large png for a Tiny example?
If so, please give the Tiny example which causes the large png, so
that we can fix that.
As far as I know, any example containing an explicit
\header{ tagline =
either requires the tagline to be present to demonstrate the bug,
or else the example is not Tiny.
This is for the bug squad, not random users. Screw the users; I
only care about volunteers. :)If you're interested in
improving things for random users, great, but that's a separate
issue from the helping-the-bug-squad work.
Cheers,
- Graham
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1701 in lilypond: default accidental style prints too many 'extra' naturals
Graham Percival gra...@percival-music.ca writes: On Thu, Jun 23, 2011 at 02:40:08PM +0200, David Kastrup wrote: lilyp...@googlecode.com writes: In light of the discussion about this patch, how hard would it be to make it controllable? I don't have a good idea of the name, since IIRC we already have an extraNatural property. As long as not a single user _wants_ the old behavior, why bother? I thought that some people _did_ want that behavior. There is some discussion about whether or not they _should_ want that behavior, but if it's easy to accommodate them, I'd rather that lilypond allow people to shoot themselves in the foot if they specifically request it. If there is no example of a composition using the feature except old Lilypond printouts, supporting this is a distraction in code and documentation. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 163 in lilypond: huge (ugly) slur (both phrasing and normal)
On 11-06-23 05:46 AM, Graham Percival wrote:
On Wed, Jun 22, 2011 at 06:52:43PM -0600, Colin Campbell wrote:
On 11-06-22 05:47 AM, Dmytro O. Redchuk wrote:
I would start with this:
Looks great; Colin, could you add that to the CG in the Issues
chapter?
That's Dmytro's script, Graham! My bash-fu is still at an early stage.
After a bit of testing, it seems that settings in \included files,
however the include is done (very smooth trick, that, David!), are
overridden if the tag exists in the destination file.
So if you run the script on
\header { tagline=foo }
\relative c' { c4}
you'll still get a tagline? IMO that's an (accidental) feature,
not a bug! Most bug reports are short and don't have a tagline
defined, so you want to trim the existing one. If a bug report
explicitly adds a tagline=abcd, then it would be good to not
trim that one. (if the tagline= is not relevant to the bug, then
the bug report should be rejected because it's not Tiny)
A problem arises when, as I suspect, the default behaviour is tagline =
##t, even when not explicitly stated in the \header block. IOW, the
absence of tagline = doesn't mean absence of a tagline. The presence
of the tagline means convert must include the entire page in the trimmed
area, which defeats the purpose of the trim.
Where a .ly file already has the tagline set, it cancels the
imported one. To do this from a script will, after all, take
some sed or perhaps python magic. I'll keep at it, as much for
education as for the satisfaction!
Well, go ahead for your own satisfaction, but I'd reject any patch
that changes the script to do this. :)
Cheers,
- Graham
If you like, I can carry on with Dmytro's script, put it into
\scripts\auxiliar with strip-whitespace and friends, then update the CG,
with a note about the taglines. Marek Klein has also reminded us about
a script Jonathan Kulp wrote in 208, called lily2image, so I'll take
that for a spin and see what it can do.
Colin
--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 163 in lilypond: huge (ugly) slur (both phrasing and normal)
On Thu 23 Jun 2011, 06:48 Colin Campbell wrote: A problem arises when, as I suspect, the default behaviour is tagline = ##t, even when not explicitly stated in the \header block. IOW, the absence of tagline = doesn't mean absence of a tagline. The presence of the tagline means convert must include the entire page in the trimmed area, which defeats the purpose of the trim. No, there is no problem, i guess. If ly file does not contain tagline, lilypond inserts default tagline -- this one can be overriden by the script. And should be, for the tracker. If ly file does contain tagline -- it either should not be overriden (fortunately enough that script can not override existing tagline) or should be removed (for a particular test.ly, let's say). -- Dmytro O. Redchuk Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.12 docs link redirects to current stable
On Thu, Jun 23, 2011 at 07:24:14PM +0200, Federico Bruni wrote: Il giorno mer, 22/06/2011 alle 18.24 +0200, Francisco Vila ha scritto: 2011/6/20 Federico Bruni fedel...@gmail.com: the link to 2.12 Docs redirects to 2.14 docs: http://lilypond.org/all.html I see it correctly pointing to 2.12, so it seems that somebody has fixed it. Right? No, nobody fixed so far. Yes, we did. The link is correct, but if you click you are redirected to http://lilypond.org/manuals.html No, you aren't. Reload the page and/or clear your browser cache, and try again. - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.12 docs link redirects to current stable
Il giorno mer, 22/06/2011 alle 18.24 +0200, Francisco Vila ha scritto: 2011/6/20 Federico Bruni fedel...@gmail.com: Hi, the link to 2.12 Docs redirects to 2.14 docs: http://lilypond.org/all.html I see it correctly pointing to 2.12, so it seems that somebody has fixed it. Right? No, nobody fixed so far. I guess that you just looked the link. The link is correct, but if you click you are redirected to http://lilypond.org/manuals.html It's a redirect rule of Apache, I guess. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.12 docs link redirects to current stable
Il giorno gio, 23/06/2011 alle 19.43 +0100, Graham Percival ha scritto: The link is correct, but if you click you are redirected to http://lilypond.org/manuals.html No, you aren't. Reload the page and/or clear your browser cache, and try again. Yes, you are right. It works now. I didn't know that redirects can be cached by browsers... ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1682 in lilypond: Website version links need updating
Updates: Status: Fixed Owner: colinpkc...@gmail.com Labels: fixed_2_15_3 Comment #8 on issue 1682 by percival.music.ca: Website version links need updating http://code.google.com/p/lilypond/issues/detail?id=1682 I believe this is fixed. Thanks, Colin! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1701 in lilypond: default accidental style prints too many 'extra' naturals
Graham Percival graham at percival-music.ca writes: On Thu, Jun 23, 2011 at 02:40:08PM +0200, David Kastrup wrote: lilypond at googlecode.com writes: In light of the discussion about this patch, how hard would it be to make it controllable? It would take a bit of thought to do without creating an extra property lookup for every note. As long as not a single user _wants_ the old behavior, why bother? I thought that some people _did_ want that behavior. Nobody so far. We are entertaining ourselves by speculating where LilyPond might have gotten the crazy idea to set those extra-extra-naturals in the first place. So far nobody has found a concrete example where the extra-extra-natural has been used. I'll wait a week as I promised, then if there have been no revelations I'll push as-is. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
