Re: TrillPitch* whiteout bug
Hi Harm,
Yes, setting ...
\override TrillPitchAccidental.layer = 3
\override TrillPitchHead.layer = 3
\override TrillPitchParentheses.layer = 2
... does work.
Thank you,
Trevor.
On Thu, Jun 27, 2024 at 11:07 PM Thomas Morley
wrote:
> Am Do., 27. Juni 2024 um 17:05 Uhr schrieb Trevor Bača <
> trevorb...@gmail.com>:
> >
> > Hi,
> >
> > Here is a two-staff example with a bug relating to the way that whiteout
> > works with TrillPitchAccidental, TrillPitchHead, TrilPitchParentheses;
> the
> > parenthesized pitched-trill fails to print, leaving behind some type of
> > visual artifact:
> >
> > %%% PITCHED-TRILL WHITEOUT BUG %%%
> >
> > \version "2.25.16"
> > \language "english"
> >
> > A = {
> > % measure 1
> > c''4
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > c''8
> > % measure 2
> > c''8
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > \once \override Beam.grow-direction = #right
> > c''16 * 29952/5120
> > [
> > c''16 * 16128/5120
> > c''16 * 13312/5120
> > c''16 * 11776/5120
> > c''16 * 10752/5120
> > ]
> > }
> >
> > B = {
> > % measure 1
> > \time 3/4
> > \set Score.proportionalNotationDuration = #(ly:make-moment 1/32)
> > \override TrillPitchAccidental.layer = 2
> > \override TrillPitchHead.layer = 2
> > \override TrillPitchParentheses.layer = 2
> > \clef "bass"
> > r16
> > \once \override TrillPitchAccidental.whiteout = ##t
> > \once \override TrillPitchHead.whiteout = ##t
> > \once \override TrillPitchParentheses.whiteout = ##t
> > \pitchedTrill
> > cs4..
> > \glissando
> > \startTrillSpan ds
> > \afterGrace
> > e4
> > {
> > f8
> > \glissando
> > }
> > % measure 2
> > \time 6/4
> > d16
> > r8.
> > \stopTrillSpan
> > r1
> > r4
> > }
> >
> > \new Score
> > <<
> > <<
> > \new Staff { \A }
> > \new Staff { \B }
> > >>
> > >>
> >
> > %%% END %%%
> >
> > [image: pitched-trill-whiteout-bug.png]
> >
> > What causes the bug to go away?
> >
> > Many things, apparently.
> >
> > Removing the upper staff causes the bug to go away:
> >
> > %%% OK WITHOUT UPPER STAFF %%%
> >
> > \version "2.25.16"
> > \language "english"
> >
> > A = {
> > % measure 1
> > c''4
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > c''8
> > % measure 2
> > c''8
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > c''16
> > \once \override Beam.grow-direction = #right
> > c''16 * 29952/5120
> > [
> > c''16 * 16128/5120
> > c''16 * 13312/5120
> > c''16 * 11776/5120
> > c''16 * 10752/5120
> > ]
> > }
> >
> > B = {
> > % measure 1
> > \time 3/4
> > \set Score.proportionalNotationDuration = #(ly:make-moment 1/32)
> > \override TrillPitchAccidental.layer = 2
> > \override TrillPitchHead.layer = 2
> > \override TrillPitchParentheses.layer = 2
> > \clef "bass"
> > r16
> > \once \override TrillPitchAccidental.whiteout = ##t
> > \once \override TrillPitchHead.whiteout = ##t
> > \once \override TrillPitchParentheses.whiteout = ##t
> > \pitchedTrill
> > cs4..
> > \glissando
> > \startTrillSpan ds
> > \afterGrace
> > e4
> > {
> > f8
> > \glissando
> > }
> > % measure 2
> > \time 6/4
> > d16
> > r8.
> > \stopTrillSpan
> > r1
> > r4
> > }
> >
> > \new Score
> > <<
> > <<
> > % \new Staff { \A } % <= THIS IS THE ONLY LINE THAT IS CHANGED
> > \new Staff { \B }
> > >>
> > >>
> >
> > %%% END %%%
> >
> > [image: ok-without-upper-staff.png]
> >
> > Strangely, the bug also goes away when the second glissando is removed
Re: Intermittent core dumps with 2.25.8 under Ubuntu 22.04.3
On Sat, Jun 1, 2024 at 2:35 AM Jean Abou Samra wrote: > > > Le 1 juin 2024 à 00:40, Trevor Bača a écrit : > > QUESTION: if Lily does core dump during one of the runs, what is the exact > path to the core file? (I'm using something like /tmp/lilypond-2.25.15 for > Lily's install directory.) > > > See https://github.com/itamarst/gha-upload-cores > Thank you, it worked. The core file is 271 MB, available at the bottom of the page here: https://github.com/trevorbaca/dornen/actions/runs/9348588969 FWIW, I think it's possible that what I am reporting here is the same as (or close to) https://gitlab.com/lilypond/lilypond/-/issues/6716. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)
On Sun, Jun 2, 2024 at 9:09 AM Werner LEMBERG wrote: > > > On my Linux machine with 2.25.16, that file nondeterministically > > compiles, segfaults, or triggers a floating point exception. No time > > to investigate more, though. > > Trevor, please open an issue! > Done. Opened as #6716. Thank you, Jean and Werner! Trevor. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
Re: Intermittent core dumps with 2.25.8 under Ubuntu 22.04.3
On Sun, Sep 24, 2023 at 9:45 AM Jean Abou Samra wrote: > Le mardi 19 septembre 2023 à 15:58 -0400, Trevor Bača a écrit : > > Happy to try to help, if anyone can offer guidance on how to better report > the problem, > > > > Having the files would obviously help a lot, if you can share them. > > If this reproducibly crashes on Linux outside of GitHub actions then it > will be enough. Otherwise we'll need a core dump. See > > > https://github.com/itamarst/gha-upload-cores/blob/main/.github/workflows/build.yml > > > for an example. > Hi Jean, Intermittent core dumps have continued under Ubuntu on GitHub actions from 2.25.8 up to, and including, 2.25.15. I finally have time to debug on GitHub actions. Following ... https://github.com/itamarst/gha-upload-cores/blob/main/.github/workflows/build.yml https://github.com/actions/upload-artifact ... I have a version of upload-artifact working in the main.yml file for the repo. QUESTION: if Lily does core dump during one of the runs, what is the exact path to the core file? (I'm using something like /tmp/lilypond-2.25.15 for Lily's install directory.) Trevor. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)
Aha, thanks for running under Windows. Further testing shows it's a bug with only the ARM distributions of 2.25.15 and 2.25.16; running on a MacBook Air with an M2 (2022) chip under macOS 14.5 gives these results: 2.25.16 (ARM): infinite loop 2.25.15 (ARM): infinite loop 2.25.16 (x86): OK 2.25.15 (x86): OK 2.25.14 (x86): OK HTH, Trevor. On Fri, May 31, 2024 at 9:31 AM wrote: > If there's a connection to Guile, we know there are some differences in > the distributions by platform. > > I would try on my Win10 system, but I managed to find myself in hospital > again. (Nothing to serious.) > > > On May 31, 2024 12:28 AM, Craig Fearing via bug-lilypond < > bug-lilypond@gnu.org> wrote: > > FWIW I ran this 15 consecutive times on my Win 11, Ryzen 7 system. One > time it took 2 seconds to compile, the rest were all 1.9 seconds. No > errors any time. > > > On 2024-05-30 23:24, Trevor Bača wrote: > > Hi, > > > > I have what appears to be a very difficult bug. > [snip] > > ... I suspect it may take two or three > > successive attempts to interpret music.ly before triggering the loop on > > some operating systems (or chip architectures), ... > > > > [snip] > > > > Trevor. > > > > > -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)
Hi,
I have what appears to be a very difficult bug.
The bug causes LilyPond 2.25.15 to sit in an infinite loop during the
"Interpreting music ..." stage of compilation.
The 3 files attached here reproduce the bug 100% of the time when I
interpret them on a 2022 M2 MacBook Air running macOS 14.5.
Crucially, the infinite loop appears to be triggered by *the total number
of music expressions read during interpretation.*
I say this after spending a couple of days bisecting the attached files:
although the music.ily file included here is large, the file is now reduced
to such a state that *commenting out almost any single voice in the
input file allows LilyPond to exit the infinite loop and finish
interpretation.* Strangely, it doesn't much appear to matter *which*
voice(s) is commented out.
Likewise, the file will interpret correctly if you comment out all
\override and \revert statements. So, too, will the file interpret
correctly if you comment out all \set stemLeftBeamCount and \set
stemRightBeamCount statements. In other words, the bug doesn't appear to be
triggered by any particular type of expression in the input files, but
rather by the total volume of expressions.
To reproduce the bug, unzip the archive attached here and call "lilypond
music.ly" inside the resulting infinite-loop directory.
When attempting to reproduce the bug, it is possible that Lily's behavior
may appear to be nondeterministic; I suspect it may take two or three
successive attempts to interpret music.ly before triggering the loop on
some operating systems (or chip architectures), even though the loop
triggers consistently on my machine.
Note, too, that LilyPond sometimes (though not always) crashes out of the
infinite loop with ...
fatal error: intlog2 with negative argument: 0
... issued before terminating.
As a hunch, my best guess is that the loop might be triggered, somehow, by
the skip-filled calls to \scaleDurations that occur in the file. These look
like \scaleDurations #'(6 . 7) { s8 s8 s8 s8 s8 s8 s8 }, and are
placeholders for empty tuplets that correspond to something going on at the
same time in another voice. (A similar bug for skipped-filled tuplets
showed up sometime around 2.25.8.) Though this wouldn't explain why such
skip-filled expressions interpret correctly when all calls to \set
stemLeftBeamCount are commented out, for example.
Apologies for the verbose files included here; I bisected to what I believe
is the minimum content to reliably trigger the loop.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
<>
Intermittent core dumps with 2.25.8 under Ubuntu 22.04.3
Hi, Moving from 2.25.7 to 2.25.8 causes intermittent core dumps under Ubuntu 22.04.3 when run on a score I've been maintaining through successive versions of LilyPond. The details here are a little tricky. The score is divided into 14 separate LilyPond files. When I build the score on my laptop (macOS, Ventura 13.5.2), LilyPond 2.25.8 interprets all 14 files perfectly; no core dumps. But when I build the score on GitHub Actions (as a type of CI running on old scores), LilyPond 2.25.8 core dumps while trying to interpret one (randomly chosen!) file of the 14 input files. GitHub Actions declares Ubuntu 22.04.3 as its operating system, and the LilyPond log at GitHub looks like this: Tue Sep 19 19:30:17 2023 Processing `/home/runner/work/dornen/dornen/dornen/sections/02/music.ly' Parsing... Interpreting music...Floating point exception (core dumped) Now for the frustrating part: I'm not sure how to further debug the problem, *because the file on which 2.25.8 core dumps appears to change every time GitHub Actions runs*. In the example above, it was the input file for the 2nd section of the score that core-dumped; on a previous run, it was section 8; and before that it was section 9. Strangely, only 1 file ever seems to core dump per run. Any advice on how to try to better report what's going on? For obvious reasons, I can't bisect the .ly file down to a single offending line. But FWIW my (completely blind) guess as to what's causing Lily to core dump is one of these to things: * grace notes * multiplied note durations (used to create feather-beam style rhythms) To be clear, I have absolutely no proof that that's what's going on. But the music features these two types of input quite a bit, and in far distant years I seem to remember one (or both?) of these things perhaps also causing a core dump (on a much, much earlier version of the LilyPond). (And perhaps the timing issues involved with grace notes would also make sense with the floating point exception raised in the error message.) Happy to try to help, if anyone can offer guidance on how to better report the problem, Trevor. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca
Re: Skip-filled tuplets crash 2.25.0
Thanks, Jean!
On Fri, Jan 13, 2023 at 5:38 PM Jean Abou Samra wrote:
> Le 13/01/2023 à 23:36, Trevor Bača a écrit :
> > Hi,
> >
> > Skip-filled tuplets halt execution in 2.25.0.
> >
> > %%% BEGIN %%%
> >
> > \version "2.25.0"
> >
> > \new Staff { \times 2/3 { s2 s2 s2 } }
> >
> > %%% END %%%
> >
> > GNU LilyPond 2.25.0 (running Guile 2.2)
> > Processing `test.ly'
> > Parsing...
> > Interpreting music...
> > warning: omitting tuplet bracket with neither left nor right bound
> > Preprocessing graphical objects...
> > /Users/trevor/lilypond-2.25.0/share/lilypond/2.25.0/ly/init.ly:65:2:
> error:
> > Guile signaled an error for the expression beginning here
> > #
> > (let ((book-handler (if (defined? 'default-toplevel-book-handler)
> > In procedure ly:grob-array-ref: Wrong type argument in position 1
> > (expecting Grob_array): ()
> >
> > It's probably true that most users aren't using skip-filled tuplets. But
> > I've been using them for quite a while in previous versions of LilyPond
> > (for certain cases of complicated polyphony where compositional processes
> > transform some, or perhaps all, notes in one voice into skips).
> >
> > Will skip-filled tuplets be allowed again in future versions of LilyPond?
> >
> > Thanks for all the goodies in 2.25!
>
>
> Thanks, but this has already been reported.
>
> https://gitlab.com/lilypond/lilypond/-/issues/6482
>
> Best,
> Jean
>
>
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
Skip-filled tuplets crash 2.25.0
Hi,
Skip-filled tuplets halt execution in 2.25.0.
%%% BEGIN %%%
\version "2.25.0"
\new Staff { \times 2/3 { s2 s2 s2 } }
%%% END %%%
GNU LilyPond 2.25.0 (running Guile 2.2)
Processing `test.ly'
Parsing...
Interpreting music...
warning: omitting tuplet bracket with neither left nor right bound
Preprocessing graphical objects...
/Users/trevor/lilypond-2.25.0/share/lilypond/2.25.0/ly/init.ly:65:2: error:
Guile signaled an error for the expression beginning here
#
(let ((book-handler (if (defined? 'default-toplevel-book-handler)
In procedure ly:grob-array-ref: Wrong type argument in position 1
(expecting Grob_array): ()
It's probably true that most users aren't using skip-filled tuplets. But
I've been using them for quite a while in previous versions of LilyPond
(for certain cases of complicated polyphony where compositional processes
transform some, or perhaps all, notes in one voice into skips).
Will skip-filled tuplets be allowed again in future versions of LilyPond?
Thanks for all the goodies in 2.25!
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
Variable names of the form section.N.S core dump the parser
Hi,
The dot-chained variable names that became available in recent versions of
LilyPond are great, particularly because they allow numerals:
%%% EXAMPLE 1 %%%
\version "2.23.8"
movement.1.notes = { g'4 }
\new Staff { \movement.1.notes }
%%% END %%%
But LilyPond's parser errors when a variable is named like this:
%%% EXAMPLE 2 %%%
\version "2.23.8"
section.1.notes = { g'4 }
\new Staff { \section.1.notes }
%%% END %%%
GNU LilyPond 2.23.8 (running Guile 2.2)
Processing `test.ly'
Parsing...ERROR: In procedure ly:parse-file:
In procedure caar: Wrong type (expecting pair): #))((display-methods
#) (name . SectionEvent) (types section-event
event)) >
The error appears to be very narrow.
Because this works ...
%%% EXAMPLE 3 %%%
\version "2.23.8"
section = { a'4 }
\new Staff { \section }
%%% END %%%
... and so does this ...
%%% EXAMPLE 4 %%%
\version "2.23.8"
section.1 = { b'4 }
\new Staff { \section.1 }
%%% END %%%
... which appears to mean that the error occurs only when a variable is
named in the form ...
section.N.S
... with numeric N and string S.
The workaround is to use a different variable name, and so the issue is
probably low priority.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Multisystem crop bug
Hi, Can somebody who interfaces with the issue tracker please open a bug for Lily's treatment of multisystem cropped images? Full thread is here; a MWE for the bug can be taken from the first post in the thread: https://lists.gnu.org/archive/html/lilypond-user/2021-01/msg00075.html It appears that what happened in that thread is that the author of the feature couldn't be convinced that the behavior described in the thread is a bug. The behavior is definitely a bug. In short, Lily removes all inter-system whitespace from cropped images. This means that multisystem crop currently destroys score layout explicitly specified by users. A further question was raised in the thread above: should the current (intersystem-whitespace-removing) behavior be preserved? Perhaps as an additional command-line option? Answer: no, the current behavior should be replaced. No user responded to the above thread asking for the current (intersystem-whitespace-removing) behavior to be preserved. On the other hand, users continue to appear on list and ask for a multisystem crop that crops only around the edges of an image: https://lists.gnu.org/archive/html/lilypond-user/2021-04/msg00121.html It would be great if we can get consensus on this and move forward. LilyPond's SVG output (and single-system cropping) are truly excellent. This combination of features has been an incredible boon to users inserting Lily-generated images on web properties. If we can nudge Lily's multisystem crop behavior the right direction, then website authors can publish beautiful multisystem LilyPond output with confidence, too. Trevor. -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \note markup
On Thu, Nov 26, 2020 at 12:27 PM Jonas Hahnfeld wrote:
> Am Donnerstag, dem 26.11.2020 um 11:39 -0500 schrieb Trevor Bača:
> > On Tue, Nov 24, 2020 at 6:57 PM Aaron Hill
> wrote:
> >
> > > On 2020-11-24 3:44 pm, Trevor Bača wrote:
> > > > Hi,
> > > >
> > > > ### BEGIN ###
> > > >
> > > > \version "2.21.80"
> > > >
> > > > \markup { \note #"4.." #UP }
> > > >
> > > > ### END ###
> > > >
> > > > GNU LilyPond 2.21.80
> > > > Processing `test.ly'
> > > > Parsing...
> > > > test.ly:3:17: error: wrong type for argument 1. Expecting duration,
> > > > found
> > > > "4.."
> > > > \markup { \note
> > > > #"4.." #UP }
> > > >
> > >
> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
> > > > In procedure reverse! in expression (ly:parse-file file-name):
> > > >
> > >
> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
> > > > Wrong type argument in position 1: (1 "4.." . #f)
> > > >
> > > > What am I missing here?
> > >
> > > The syntax changed. You no longer specify the duration as a string,
> but
> > > as a duration:
> > >
> > >
> > > \markup { \note 4.. #UP }
> > >
> > >
> >
> > In 2.21.80?
> >
> > I'm getting something like this:
> >
> > %%%
> > \version "2.21.80"
> > \markup { \note 4.. #UP }
> > %%%
> >
> > GNU LilyPond 2.21.80
> > Processing `test.ly'
> > Parsing...
> > test.ly:2:17: error: syntax error, unexpected SYMBOL
> > \markup { \note
> > 4.. #UP }
> > test.ly:2:26: error: Unfinished main input
> > \markup { \note 4.. #UP }
> >
> > fatal error: failed files: "test.ly"
>
> As David said, the right tool for this is convert-ly. And it will
> convert the example (if you say \version "2.20.0" at the beginning) to:
>
> \markup { \note {4..} #UP }
>
> (note the curly braces)
>
Works perfectly. Thank you!
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \note markup
On Tue, Nov 24, 2020 at 6:57 PM Aaron Hill wrote:
> On 2020-11-24 3:44 pm, Trevor Bača wrote:
> > Hi,
> >
> > ### BEGIN ###
> >
> > \version "2.21.80"
> >
> > \markup { \note #"4.." #UP }
> >
> > ### END ###
> >
> > GNU LilyPond 2.21.80
> > Processing `test.ly'
> > Parsing...
> > test.ly:3:17: error: wrong type for argument 1. Expecting duration,
> > found
> > "4.."
> > \markup { \note
> > #"4.." #UP }
> >
> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
> > In procedure reverse! in expression (ly:parse-file file-name):
> >
> /Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
> > Wrong type argument in position 1: (1 "4.." . #f)
> >
> > What am I missing here?
>
> The syntax changed. You no longer specify the duration as a string, but
> as a duration:
>
>
> \markup { \note 4.. #UP }
>
>
In 2.21.80?
I'm getting something like this:
%%%
\version "2.21.80"
\markup { \note 4.. #UP }
%%%
GNU LilyPond 2.21.80
Processing `test.ly'
Parsing...
test.ly:2:17: error: syntax error, unexpected SYMBOL
\markup { \note
4.. #UP }
test.ly:2:26: error: Unfinished main input
\markup { \note 4.. #UP }
fatal error: failed files: "test.ly"
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
\note markup
Hi,
### BEGIN ###
\version "2.21.80"
\markup { \note #"4.." #UP }
### END ###
GNU LilyPond 2.21.80
Processing `test.ly'
Parsing...
test.ly:3:17: error: wrong type for argument 1. Expecting duration, found
"4.."
\markup { \note
#"4.." #UP }
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
In procedure reverse! in expression (ly:parse-file file-name):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily.scm:1036:21:
Wrong type argument in position 1: (1 "4.." . #f)
What am I missing here?
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Crash from embedded comment
Hi,
This causes Lily to crash:
### BEGIN ###
\version "2.21.80"
\new Score
<<
\new GlobalContext { s1 }
\new Staff { c'1 }
>>
\layout {
\context {
\name GlobalContext
\type Engraver_group
\consists Axis_group_engraver
\override VerticalAxisGroup.default-staff-staff-spacing = #'(
(basic-distance . 0)
(minimum-distance . 12) % errant comment causes crash
(padding . 0)
(stretchability . 0)
)
}
\context {
\Score
\accepts GlobalContext
}
}
### END ###
GNU LilyPond 2.21.80
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing
systems.../Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily-library.scm:247:5:
In procedure ly:optimal-breaking in expression (process-procedure book
paper ...):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/lily-library.scm:247:5:
Wrong type (expecting pair): %
The input worked through the end of 2.19.
Presumably 2.21 changes something with the way LilyPond comments are parsed
from within Scheme blocks.
But this should error during parsing. And alert the user with a line number
from the input .ly file. The output shown above makes it look like there's
something wrong with lily-library.scm.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
"Including" stdin hangs LilyPond during parsing
Hi,
### BEGIN ###
\version "2.20.0"
\include "-"
\new Staff
{
c'4
}
### END ###
Hangs during parsing:
GNU LilyPond 2.20.0
Processing `test.ly'
Parsing...
< hangs forever >
Presumably the (spurious) filename "-" dereferences to stdin, putting Lily
in a wait state for user input that's never to come.
Seems unlikely anyone would ever type such a thing. But maybe a
special-cased check wouldn't hurt.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: [bug] 2.20.0 -> 2.21.1 Multi_measure_rest_engraver
On Wed, May 6, 2020 at 7:06 PM David Kastrup wrote:
> Valentin Villenave writes:
>
> > On 5/6/20, Trevor Bača wrote:
> >> The following MWE works under 2.20.0 but crashes LilyPond under 2.21.1.
> >
> > Wow, that’s a nice one. I’m marking this as Critical because its a/ a
> > segfault, b/ a regression and c/ not that unusual a use case.
> > https://sourceforge.net/p/testlilyissues/issues/5964/
> > Since it got broken recently, that should be fairly easy to bisect.
>
> Uh, there are several years of development between 2.20.0 and 2.21.1.
> Unfortunately. But at least few version changes...
>
Actually, only one version to check! The problem entered sometime between
2.19.84 and 2.21.1.
MWE works under 2.19.84:
### WORKS UNDER 2.19.84 ###
\version "2.19.84"
\layout {
\context {
\name GlobalRests
\type Engraver_group
\consists Multi_measure_rest_engraver
}
\context {
\name GlobalContext
\type Engraver_group
\accepts GlobalRests
}
\context {
\Score
\accepts GlobalContext
}
}
\new Score
<<
\new GlobalContext
{
\new GlobalRests { R1 }
}
\new Staff { \time 4/4 R1 }
>>
### END ###
GNU LilyPond 2.19.84
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to
`/var/folders/0k/3dbjvd1548b0wkstx2lyb60wgn/T//lilypond-3FIYkv'...
Converting to `test.pdf'...
Deleting
`/var/folders/0k/3dbjvd1548b0wkstx2lyb60wgn/T//lilypond-3FIYkv'...
Success: compilation successfully completed
HTH,
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
[bug] 2.20.0 -> 2.21.1 Multi_measure_rest_engraver
Hi,
The following MWE works under 2.20.0 but crashes LilyPond under 2.21.1.
### WORKS UNDER 2.20.0 ###
\version "2.20.0"
\layout {
\context {
\name GlobalRests
\type Engraver_group
\consists Multi_measure_rest_engraver
}
\context {
\name GlobalContext
\type Engraver_group
\accepts GlobalRests
}
\context {
\Score
\accepts GlobalContext
}
}
\new Score
<<
\new GlobalContext
{
\new GlobalRests { R1 }
}
\new Staff { \time 4/4 R1 }
>>
### END ###
GNU LilyPond 2.20.0
Processing `illustration.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to
`/var/folders/0k/3dbjvd1548b0wkstx2lyb60wgn/T//lilypond-kmhqj8'...
Converting to `illustration.pdf'...
Deleting
`/var/folders/0k/3dbjvd1548b0wkstx2lyb60wgn/T//lilypond-kmhqj8'...
Success: compilation successfully completed
[image: mmrest.png]
### CRASHES UNDER 2.21.1 ###
\version "2.21.1"
\layout {
\context {
\name GlobalRests
\type Engraver_group
\consists Multi_measure_rest_engraver
}
\context {
\name GlobalContext
\type Engraver_group
\accepts GlobalRests
}
\context {
\Score
\accepts GlobalContext
}
}
\new Score
<<
\new GlobalContext
{
\new GlobalRests { R1 }
}
\new Staff { \time 4/4 R1 }
>>
### END ###
GNU LilyPond 2.21.1
Processing `illustration.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
< halt >
The workaround appears to be to use 2.20.0 until the 2.21.1 bug can be
tracked down.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Rests with stem tremolo cause LilyPond to fail silently
Hi,
While "c4:32" correctly expresses a quarter note stem tremolo slashes,
typing (badly-formed) "r4:32" probably only happens when a user is editing
a source file and changes a note to a rest without regard for the stem
tremolo suffix.
However, rather than raising some type of error or warning, Lily fails
silently on this type of badly-formed construction.
Rests shorter than the duration of a whole note cause LilyPond to fail
silently at system drawing:
%%% BEGIN 1 %%%
\version "2.19.83"
\new Staff { r4:32 }
%%% END %%%
Output:
GNU LilyPond 2.19.83
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
*[no more output]*
Longer rests cause Lily to fail even more laconically:
%%% BEGIN 2 %%%
\version "2.19.83"
\new Staff { r1:32 }
%%% END %%%
GNU LilyPond 2.19.83
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
*[no more output]*
Rather than failing silently, Lily should raise an error or warning:
imagine a large input file failing for no apparent reason and then having
to bisect the entire thing find a single instance of something like
"r4:32".
Thanks,
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Core dump: page-breaking.cc (line 1180) with \autoPageBreaksOff [2.19.83]
Hi,
The page-breaker core dumps in the following example:
%%% BEGIN BUG %%%
\version "2.19.83"
notes = {
c'4 c'4 c'4 c'4 c'4
c'4 c'4 c'4 c'4 c'4
c'4 c'4 c'4
}
\layout {
\context {
\name TimeSignatureContext
\type Engraver_group
\consists Axis_group_engraver
\consists Time_signature_engraver
\override TimeSignature.font-size = 3
}
\context {
\Score
\accepts TimeSignatureContext
}
}
\context Score = "Score"
<<
\context TimeSignatureContext = "Time_Signature_Context"
{
\autoPageBreaksOff
\time 5/4
s1 * 5/4
\time 5/4
s1 * 5/4
\time 1/4
s1 * 3/4
}
\context Staff = "Staff_I"
\context Voice \notes
\context Staff = "Staff_II"
\context Voice \notes
\context Staff = "Staff_III"
\context Voice \notes
\context Staff = "Staff_IV"
\context Voice \notes
>>
%%% END BUG %%%
Output:
GNU LilyPond 2.19.83
Processing `illustration.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1
page.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-test/lily/page-breaking.cc:1180:
failed assertion `ret <= cached_line_details_.size ()'
Note, oddly, that almost every line in the MWE above needs to be present to
trigger the core. That is: commenting out \autoPageBreaksOff prevents the
core; reducing the example from four staves to three staves prevents the
core; selecting a different series of time signatures for the example
prevents the core (?!); even commenting out the TimeSignature.font-size
override prevents the core (?!).
Thanks,
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug: restarting staff destroys DynamicLineSpanner.staff-padding after line break
On Thu, Mar 7, 2019 at 2:14 AM David Kastrup wrote:
> Trevor Bača writes:
>
> > Restarting the staff during the lifespan of a multisystem
> > DynamicLineSpanner destroys the value of DynamicLineSpanner properties
> > (like staff-padding) that were set when the DynamicLineSpanner was
> > created.
>
> It doesn't. It's just that the DynamicLineSpanner has a relation with
> the Staff it was started in.
>
> > In the MWE below, the hairpin should exhibit staff-padding equal to 10
> > staff spaces below all four systems; but the value of staff-padding is
> lost
> > at the point (in system 2) that the staff is restarted; we see evidence
> of
> > this after the next line break (in systems 3 and 4) where no staff
> padding
> > appears.
> >
> > %%% BEGIN %%%
> >
> > \version "2.19.82"
> >
> > \new Staff
> > {
> >
> > \override DynamicLineSpanner.staff-padding = 10
> > c'1
> > \p
> > \<
> > c'1
> > c'1
> > \break
> >
> > c'1
> > \stopStaff
> > \startStaff
> > c'1
> > c'1
> > \break
> >
> > c'1
> > c'1
> > c'1
> > \break
> >
> > c'1
> > c'1
> > c'1
> > \f
> >
> > }
> >
> > \paper
> > {
> > indent = 0
> > ragged-right = ##t
> > system-system-spacing.minimum-distance = 30
> > }
> >
> > %%% END %%%
> >
> > [image: restart-staff-dynamic-line-spanner-bug.png]
>
> If you start a new DynamicLineSpanner like
>
> c'1\!
> \stopStaff
> \startStaff
> c'1\<
>
> it will be properly spaced. It's probably not the only spanner
> unprepared to span pieces of interrupted staff symbols.
>
Isn't this still a bug? Or, rather a gap in system functionality for which
no workaround exists?
Starting a new DynamicLineSpanner creates two separate hairpins:
%%% BEGIN %%%
\version "2.19.82"
\new Staff
{
\override DynamicLineSpanner.staff-padding = 10
c'1
\p
\<
c'1
c'1
\break
c'1
\!
\stopStaff
\startStaff
c'1
\<
c'1
\break
c'1
c'1
c'1
\break
c'1
c'1
c'1
\f
}
\paper
{
indent = 0
ragged-right = ##t
system-system-spacing.minimum-distance = 30
}
%%% END %%%
[image: two-hairpins-instead-of-one.png]
... when what's needed is one single hairpin that governs the music of all
four systems.
Or am I missing something, and there is a way to generate a single
multisystem hairpin that governs all four systems?
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug: restarting staff destroys DynamicLineSpanner.staff-padding after line break
Hi,
Restarting the staff during the lifespan of a multisystem
DynamicLineSpanner destroys the value of DynamicLineSpanner properties
(like staff-padding) that were set when the DynamicLineSpanner was created.
In the MWE below, the hairpin should exhibit staff-padding equal to 10
staff spaces below all four systems; but the value of staff-padding is lost
at the point (in system 2) that the staff is restarted; we see evidence of
this after the next line break (in systems 3 and 4) where no staff padding
appears.
%%% BEGIN %%%
\version "2.19.82"
\new Staff
{
\override DynamicLineSpanner.staff-padding = 10
c'1
\p
\<
c'1
c'1
\break
c'1
\stopStaff
\startStaff
c'1
c'1
\break
c'1
c'1
c'1
\break
c'1
c'1
c'1
\f
}
\paper
{
indent = 0
ragged-right = ##t
system-system-spacing.minimum-distance = 30
}
%%% END %%%
[image: restart-staff-dynamic-line-spanner-bug.png]
Thanks,
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Proportional spacing bug: chained \noBreaks + \newSpacingSection
Hi,
LilyPond incorrectly compresses consecutive, proportionally spaced measures
when the following conditions hold:
1. first measure in the sequence sets \proportionalNotationDuration; and
2. last measure in sequence is followed by \newSpacingSection; and
3. all measures in sequence carry \noBreak commands.
%%% BEGIN SPACING BUG %%%
\version "2.19.82"
\layout {
indent = #0
ragged-right = ##t
}
\new Staff
\with
{
\remove Time_signature_engraver
}
{
\time 2/8
\set Score.proportionalNotationDuration = #(ly:make-moment 1 32)
c'4
^ \markup \with-color #red "First three measures aren't wide enough"
\noBreak
c'4
\noBreak
c'4
\noBreak
\newSpacingSection
c'4
c'4
c'4
c'4
c'4
}
%%% END %%%
Output looks like this:
[image: no-break-spacing-bug.png]
Correct output looks like this:
%%% BEGIN NON-BUG %%%
\version "2.19.82"
\layout {
indent = #0
ragged-right = ##t
}
\new Staff
\with
{
\remove Time_signature_engraver
}
{
\time 2/8
\set Score.proportionalNotationDuration = #(ly:make-moment 1 32)
c'4
c'4
c'4
\newSpacingSection
c'4
c'4
c'4
c'4
c'4
}
%%% END %%%
Visual:
[image: correct-output.png]
Note, again, that *all* measures spaced incorrectly must carry a \noBreak
command; removing *any one* of the three \noBreak commands in the bug
snippet causes the bug to disappear.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Core dump: measure-final, length-1 tuplet + tight spacing
Hi,
This very specific combination of circumstances causes Lily to core dump:
1. A length-1 tuplet (ie, tuplet containing only a single note or rest);
that
2. occurs as the last element of a measure; followed by
3. more music in the following measure; and with
4. proportional spacing turned on and set to a value that is "too tight"
%%% BEGIN CORE DUMP %%%
\version "2.19.82"
\new Staff
{
\override Score.SpacingSpanner.strict-grace-spacing = ##t
\override Score.SpacingSpanner.strict-note-spacing = ##t
\override Score.SpacingSpanner.uniform-stretching = ##t
\set Score.proportionalNotationDuration = #(ly:make-moment 1 16)
\set Score.tupletFullLength = ##t
c'2.
c'16
c'16
c'16
\times 1/1
{
c'16
}
c'1
}
%%% END CORE DUMP %%%
Lily output:
GNU LilyPond 2.19.82
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing
systems.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/interval.hh:227:
failed assertion `!is_empty ()'
Increasing proportional spacing from 1/16 up to, say, 1/32 makes the
problem go away; this is the workaround to document until the bug is fixed.
(Choice of time signature, multiplier of the tuplet, vertical position of
notes on the staff all make no difference in resulting behavior.)
I think the problem's been in Lily for a while (it's definitely not a
2.19.82-only bug); it entered sometime during or after 2014.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
\stopStaff at \break makes SpanBar disappear
Hi,
Stopping-and-restarting the staff at line break makes SpanBar disappear:
### BEGIN ###
\version "2.19.80"
\new Score <<
\new StaffGroup <<
\new Staff {
c'1
\break
\stopStaff
\once \override Staff.StaffSymbol.line-count = 3
\startStaff
c'1
}
\new Staff {
c'1
c'1
}
\new Staff {
c'1
c'1
}
\new Staff {
c'1
c'1
}
>>
>>
### END ###
Note that the problem appears to a fence-posting error: *the bug arises
only when stopping-and-restarting *the topmost staff* (as shown above) or
*the bottommost staff**; stopping-and-restarting any of the inner staves in
the staff group does not trigger the bug.
Thanks,
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Make flared hairpins work with the circled-tip property
Hi David, This is really helpful; I hadn't noticed the workaround attached to the issue. Thanks very much for pointing it out. Integrating now and it looks like the workaround does what I need! Trevor. On Wed, Apr 6, 2016 at 2:52 PM, David Nalesnik <david.nales...@gmail.com> wrote: > Hi, > > On Wed, Apr 6, 2016 at 2:47 PM, Simon Albrecht <simon.albre...@mail.de> > wrote: > >> Hi Trevor, >> >> that’s a known deficiency: >> >> <https://sourceforge.net/p/testlilyissues/issues/search/? >> q=flared+%26%26+niente> >> >> Best, >> Simon >> >> > Note that a workaround is attached to the issue. > > David > -- Trevor Bača www.trevorbaca.com soundcloud.com/trevorbaca ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Make flared hairpins work with the circled-tip property
Hello,
Flared hairpins work:
### BEGIN ###
\version "2.19.39"
\new Staff {
\override Hairpin.stencil = #flared-hairpin
c'2 \<
d'2
e'1 \f
}
### END ###
And circled-tip hairpins work, too:
### BEGIN ###
\version "2.19.39"
\new Staff {
\override Hairpin.circled-tip = ##t
c'2 \<
d'2
e'1 \f
}
### END ###
But when the two are combined, the circled tip fails to appear:
### BEGIN ###
\version "2.19.39"
\new Staff {
\override Hairpin.circled-tip = ##t
\override Hairpin.stencil = #flared-hairpin
c'2 \<
d'2
e'1 \f
}
### END ###
(I imagine that what's going on is that the flared-hairpin stencil hasn't
yet been taught about the circled-tip property.)
It would be really lovely if these two features could work together; the
musical directive is quite useful: "crescendo dal niente to assume the
end-dynamic subito."
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Length-1 tuplets crash LilyPond (with strict-note-spacing & tupletFullLength)
Thanks for the confirmation of version, Simon.
For what it's worth, the bad output is no problem in actual scores because
other layout settings will be used to space everything correct, move time
signatures around and so on. It's only the crashing of the system that is a
problem.
Also, the work-around is to to set \fullLengthTuplet = ##f for the duration
of just the problematic tuplet in question. (Maybe the work-around should
be added to the tracker.)
Trevor.
On Wed, Sep 16, 2015 at 7:06 PM, Simon Albrecht <simon.albre...@mail.de>
wrote:
> On 16.09.2015 23:04, Trevor Bača wrote:
>
>> \version "2.19.27"
>>
>> \layout {
>> \context {
>> \Score
>> \override SpacingSpanner #'strict-note-spacing = ##t
>> tupletFullLength = ##t
>> }
>> }
>>
>> \new Staff {
>> \time 1/8
>> \times 2/3 {
>> c'8.
>> }
>> \time 5/8
>> \times 2/3 {
>> c'8.
>> c'8.
>> c'8.
>> c'8.
>> c'8.
>> }
>> }
>>
>
>
>> The bug is present under 2.19.26 and 2.19.27; I haven't tested under early
>> versions.
>>
>
> Up to 2.19.20, there is no error, but the output is bad (see attached).
> From 2.19.22, the error occurs.
>
> Yours, Simon
>
>
--
Trevor Bača
www.trevorbaca.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Length-1 tuplets crash LilyPond (with strict-note-spacing & tupletFullLength)
Hi,
I've been using length-1 tuplets in my music recently. (Length-1 tuplets
being tuplets with only a single note or rest.) It's quite wonderful that
Lily handles these things correctly (just like how the system handles
unusual time signatures like 1/12 and 5/14, too).
But I've now uncovered a bug that crashes LilyPond during the drawing stage
of interpretation.
Drawing
systems.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/include/interval.hh:227:
failed assertion `!is_empty ()'
Minimal example:
%%% BEGIN BUG %%%
\version "2.19.27"
\layout {
\context {
\Score
\override SpacingSpanner #'strict-note-spacing = ##t
tupletFullLength = ##t
}
}
\new Staff {
\time 1/8
\times 2/3 {
c'8.
}
\time 5/8
\times 2/3 {
c'8.
c'8.
c'8.
c'8.
c'8.
}
}
GNU LilyPond 2.19.27
Processing `illustration.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing
systems.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/include/interval.hh:227:
failed assertion `!is_empty ()'
%%% END BUG %%%
Three conditions must be met to trigger the bug:
1. strict-note-spacing must be true.
2. tupletFullLength must be true.
3. further note input must follow the length-1 tuplet
The following three modified examples help illustrate these conditions:
%%% BEGIN COUNTEREXAMPLE 1 %%%
\version "2.19.27"
\layout {
\context {
\Score
*% example works with strict-note-spacing commented-out*
%\override SpacingSpanner #'strict-note-spacing = ##t
tupletFullLength = ##t
}
}
\new Staff {
\time 1/8
\times 2/3 {
c'8.
}
\time 5/8
\times 2/3 {
c'8.
c'8.
c'8.
c'8.
c'8.
}
}
%%% END %%%
%%% BEGIN COUNTEREXAMPLE 2 %%%
\version "2.19.27"
\layout {
\context {
\Score
\override SpacingSpanner #'strict-note-spacing = ##t
*% example works with tupletFullLength commented-out*
%tupletFullLength = ##t
}
}
\new Staff {
\time 1/8
\times 2/3 {
c'8.
}
\time 5/8
\times 2/3 {
c'8.
c'8.
c'8.
c'8.
c'8.
}
}
%%% END %%%
%%% BEGIN COUNTEREXAMPLE 3 %%%
\version "2.19.27"
\layout {
\context {
\Score
\override SpacingSpanner #'strict-note-spacing = ##t
tupletFullLength = ##t
}
}
\new Staff {
\time 1/8
\times 2/3 {
c'8.
}
*% example works with second tuplet commented out*
%\time 5/8
%\times 2/3 {
%c'8.
%c'8.
%c'8.
%c'8.
%c'8.
%}
}
%%% END %%%
The bug is present under 2.19.26 and 2.19.27; I haven't tested under early
versions.
Thank you for all of the wonderful work in support of LilyPond's rhythmic
time-keeping,
Trevor.
--
Trevor Bača
www.trevorbaca.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New install problem
On Mon, Jul 25, 2011 at 7:03 AM, James Lowe james.l...@datacore.com wrote: Hello, )-Original Message- )From: Floris van Manen [mailto:v...@klankschap.nl] )Sent: 25 July 2011 11:38 )To: James Lowe )Cc: bug-lilypond@gnu.org bug )Subject: Re: New install problem )Importance: Low ) ) )On Jul 25, 2011, at 12:03, James Lowe wrote: ) ) What version of Mac OS are you using... Lion by any chance? ) )I got the same error and i'm using OSX 10.7 Lion indeed. ) For now, I have opened an issue for this including the error message http://code.google.com/p/lilypond/issues/detail?id=1781 FWIW, running 2.5.15 *from the commandline* under Lion works great for me. Trevor. -- Trevor Bača trevorb...@gmail.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: New install problem
On Mon, Jul 25, 2011 at 11:20 AM, Floris van Manen v...@klankschap.nl wrote: On Jul 25, 2011, at 17:12, Trevor Bača wrote: FWIW, running 2.5.15 *from the commandline* under Lion works great for me. not here... $ Downloads/LilyPond.app/Contents/MacOS/LilyPond Ah: it's LilyPond.app/Contents/Resources/bin/lilypond that runs for me under Lion. Trevor. -- Trevor Bača trevorb...@gmail.com ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tempo / tuplet bracket bug
Hi,
The following snippet exhibits a bug in the form of contention between
metronome mark and tuplet instantiation:
%%% BEGIN TEMPO INSTANTIATION BUG %%%
\version 2.13.9
\new Staff {
\time 2/8
\times 2/3 {
\tempo 8=52
c'8 (
c'8
c'8
}
\time 2/8
c'8
c'8 )
}
%%% END TEMPO INSTANTIATION BUG %%
The interpreter gives the following warnings:
GNU LilyPond 2.13.9
Processing `0329.ly'
Parsing...
Interpreting music...
programming error: stopped tuplet bracket has left nor right bound.
continuing, cross fingers
0329.ly:10:10: warning: unterminated slur
c'8
(
0329.ly:16:10: warning: cannot end slur
c'8
)
Preprocessing graphical objects...
Solving 1 page-breaking chunks...[1: 1 pages]
Drawing systems...
And the output is attached here as tuplet-bracket-bound-bug.png.
The problem apparently has to do with the lexical spot at which the tempo
mark instantiates. Moving the tempo mark prior to the tuplet \times command
provides a workaround:
%%% BEGIN WORKAROUND %%%
\version 2.13.9
\new Staff {
\time 2/8
\tempo 8=52
\times 2/3 {
c'8 (
c'8
c'8
}
\time 2/8
c'8
c'8 )
}
%%% END WORKAROUND %%%
Note that what makes this one particularly slippery is that the output from
the buggy example (shown in the png attached here) is actually syntactically
wrong: the measure of 2/8 prints with three eighth notes (because the tuplet
bracket goes missing). The rhythmic inaccuracy is easy enough to spot in
this pared-down example; but in a situation of considerably more rhythmic
complexity this can be lethal. (In the realworld score that I am working on
that surfaced the bug it was, in fact, only the very visible absence of an
extended slur that made this one possible to find.)
Trevor.
--
Trevor Bača
trevorb...@gmail.com
attachment: tuplet-bracket-bound-bug.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug: dyadic accidental overprint
On Wed, Jan 7, 2009 at 5:22 PM, Neil Puttock n.putt...@gmail.com wrote: Hi Trevor, 2009/1/7 Trevor Bača trevorb...@gmail.com: Hi, Could someone check and see if this one is already in the tracker? It certainly is; have a look at issue #546. Joe posted a patch to fix it, which seems to work fine (see image below). There's a slight problem with the notehead positioning, but I have a vague recollection that the gap between the heads is chosen deliberately, since it tends to produce better looking chords. Hi Neil, OK, super, though sorry for the duplicate report! The output of Joe's patch looks great to me. The spacing between both the accidentals and the notes comprising the dyad looks good in the png you sent along. Thanks much! Trevor. -- Trevor Bača trevorb...@gmail.com ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug: dyadic accidental overprint
Hi,
Could someone check and see if this one is already in the tracker?
%%% BEGIN %%%
\version 2.11.65
\include english.ly
\new Staff {
\time 1/4
ef' es'4 % accidental overprint
ef' e'!4 % accidental overprint
ef' eqf'4 % accidental overprint
es' eqs'4 % accidental overprint
}
%%% END %%%
Oh, and happy New Year! Looking forward to trying 2.12 soon ...
Trevor.
--
Trevor Bača
trevorb...@gmail.com
attachment: accidental-overprint.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming error: when \break used before \grace or after \afterGrace in combination with proportional notation
2008/11/20 V!ctor Adán [EMAIL PROTECTED]
Update,
I'm pretty sure now that the problem is in these two overrides:
\override SpacingSpanner #'strict-note-spacing = ##t
\override SpacingSpanner #'strict-grace-spacing = ##t
It turns out that grace notes coinciding with line/page breaks *can*
compile without errors while setting
proportionalNotationDuration = #(ly:make-moment )
as long as the strict-note-spacing and/or strict-grace-spacing are NOT set
to True.
Setting only
\override SpacingSpanner #'uniform-stretching = ##t
gives no errors.
So at this point we have a compromise between being able to have grace (or
afterGrace) notes on line breaks and having strict-note-spacing in
proportional notation.
So the following compiles correctly:
%% START
\version 2.11.64
\include english.ly
\layout{
\context{ \Score
proportionalNotationDuration = #(ly:make-moment 1 32)
\override SpacingSpanner #'uniform-stretching = ##t
}
}
{
\new Voice{
\time 1/4
c'4
\break
\afterGrace c'4 {g'64}
\break
c'4
\break
c'4
\break
}
\new Voice{
\time 1/4
c'4
\break
\grace{ g'64 }
c'4
\break
c'4
\break
c'4
\break
}
}
%%% END %%%
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 to turn on strict-note-spacing,
too.)
Trevor.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming error: when \break used before \grace or after \afterGrace in combination with proportional notation
On Fri, Nov 14, 2008 at 4:35 PM, V!ctor Adán [EMAIL PROTECTED] wrote:
Hello All,
After trying for hours to figure out why my LilyPond score was generating
programming error messages on compilation, I finally found the culprit and
was able to come up with a pair of minimal examples generating the errors. I
searched the mailing lists for solutions to this, but I found no posts of
this specific problem, so I guess this is new.
The problem seems to be occur when combining three things:
1. proportional notation:
proportionalNotationDuration = #(ly:make-moment 1 34)
\override SpacingSpanner #'strict-note-spacing =##t
2. \grace or \afterGrace notes
3. \break or \pageBreak immediately before \grace or immediately after
\afterGrace notes.
The two errors I get are:
programming error: bounds of spanner are invalid
and
programming error: No spring between column 1 and next one
continuing, cross fingers
If I remove the strict-note-spacing = ##t assignment, everything works
fine.
Minimal code examples are included here, together with the LilyPond output.
Any ideas how this can be fixed or how to go around it? Is this a bug?
Many thanks,
V!ctor Adan.
PS Since this seems like a bug, I'm sending to the bug-lilypond mailing
list too, just in case.
%% CODE BEGINS %
\version 2.11.64
\include english.ly
\layout{
\context{ \Score
proportionalNotationDuration = #(ly:make-moment 1 34)
\override SpacingSpanner #'strict-note-spacing =##t
%\override SpacingSpanner #'strict-grace-spacing = ##t
%\override SpacingSpanner #'uniform-stretching = ##t
}
}
%% EXAMPLE 1 (afterGrace)
{
\new Voice{
\time 1/4
c'4
\break
\afterGrace c'4 {g'64}
\break
c'4
\break
c'4
}
}
% %% LILYPOND OUTOUT:
% GNU LilyPond 2.11.64
% Processing `test.ly'
% Parsing...
% Interpreting music...
% Preprocessing graphical objects...
% Finding the ideal number of pages...
% Fitting music on 1 page...
% Drawing systems...
% programming error: bounds of spanner are invalid
% programming error: bounds of spanner are invalid
% programming error: bounds of spanner are invalid
% programming error: bounds of spanner are invalid
% programming error: bounds of spanner are invalid
% programming error: bounds of spanner are invalid
% Layout output to `test.ps'...
% Converting to `./test.pdf'...
% EXAMPLE 2 (grace) %%%
{
\new Voice{
\time 1/4
c'4
\break
\grace{ g'64 }
c'4
\break
c'4
\break
c'4
}
}
% %% LILYPOND OUTOUT:
% GNU LilyPond 2.11.64
% Processing `test.ly'
% Parsing...
% Interpreting music...
% Preprocessing graphical objects...
% programming error: No spring between column 1 and next one
% continuing, cross fingers
% programming error: No spring between column 2 and next one
% continuing, cross fingers
% programming error: No spring between column 2 and next one
% continuing, cross fingers
% programming error: No spring between column 2 and next one
% continuing, cross fingers
% programming error: No spring between column 1 and next one
% continuing, cross fingers
% Finding the ideal number of pages...
% Fitting music on 1 page...
% Drawing systems...
% programming error: No spring between column 2 and next one
% continuing, cross fingers
% programming error: No spring between column 1 and next one
% continuing, cross fingers
% Layout output to `test.ps'...
% Converting to `./test.pdf'...
CODE ENDS
%%http://lists.gnu.org/mailman/listinfo/lilypond-user
Hi Víctor,
Wow: insane. That is absolutely a bug. Breaks on my end (2.11.57), too.
I fear, however, that this particular bug has probably been around since
inception. And it doesn't completely surprise me, either: up through
February (when I was finishing up the trio) 'weird things' would happen if I
had graces come at the beginning of a line; proportional notation was, of
course, turned on. I actually had to go back and strip out beginning-of-line
graces in the piece. The grace stripping wasn't too much of a loss for me
... but I'd be willing to be that you're going to be using graces next to
line breaks all over, aren't you?
Trevor.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \once \override Beam doesn't work anymore?
On Tue, May 13, 2008 at 11:20 AM, karim haddad [EMAIL PROTECTED] wrote: Hi Apparently in \version 2.11.46 \once \override Beam #'positions doesn't work . Only the \override will. But how can we go back to the default setting then ? Or am i missing something here ? Hi Karim, What are the chances that your \once \override happens *after* the beam has already begun?? Trevor. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \once \override Beam doesn't work anymore?
Right. I was reading up through unanswered mail and unfortunately sent the response before seeing the rest of the splintered thread! Thanks! 2008/6/2 Valentin Villenave [EMAIL PROTECTED]: 2008/6/2 Trevor Bača [EMAIL PROTECTED]: What are the chances that your \once \override happens *after* the beam has already begun?? Hi Trev, thanks for tracking this one down, but in fact it's been addressed in another thread: http://lists.gnu.org/archive/html/bug-lilypond/2008-05/msg00116.html Cheers, Valentin -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond-book 2.11.43 broken
On Wed, Mar 26, 2008 at 1:49 AM, Graham Percival [EMAIL PROTECTED] wrote:
On Tue, 25 Mar 2008 23:05:35 -0300
Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
2008/3/25, Graham Percival [EMAIL PROTECTED]:
lilypond-book 2.11.43 from OSX GUB is broken for normal usage (ie
I'm not complaining about the docs here. :)
I don't quite know enough about python to figure out what you're
trying to do on line 1633, sorry.
is this py 2.3 or 2.4 ?
2.4.4 -- I installed an updated python from macports for some
other software (although I can't think of what it was right now).
lilypond-book in 2.11.42 worked fine. For now I just copied the
script from the 2.11.42 GUB and dumped it inside the 2.11.43
package.
Hi Graham, hi Han-Wen,
Similar problem here when I upgraded to 2.11.43-2 on my OS X (10.4 -- *not*
Leopard) box at home this morning. It appears to be a python versioning
problem. The OS directive at the head of lilypond-book is finding python
with #!/usr/bin/python ... which aliases to python 2.3.5 on my system; this
is a spurious python install on my box. I prefer to use python 2.5 and
which python gives
/Library/Frameworks/Python.framework/Versions/Current/bin/python, (which is,
in fact, 2.5).
So, what this comes out to mean is that the global references to the set( )
constructor in lilypond-book all break if /usr/bin/python is used because
set( ) didn't become a python built-in until 2.4 (or thereabouts). Yes, I
know it's weird for me to have multiple versions of python installed on my
box and I can't remember why it's like this ... something to do with the
.dmgs I downloaded. But the real solution is for lilypond-book to summon
whatever version of python appears on the user path; in my case this will be
python 2.5, set( ) will be built-in, and everything will work great.
I don't understand lilypond-book well enough to change the version of python
that the script is looking for. But adding ...
from sets import Set as set
... to the import statements at the head of the script fixes the problem for
now.
Odd that everything worked great through 2.11.41, at least, and the set( )
stuff only becomes a problem in 2.11.43.
### DETAILS ###
Minimal lilypond-book test file:
\documentclass[10pt]{article}
\begin{document}
hello, world!
\begin{lilypond}
\new Staff {
c'4
}
\end{lilypond}
\end{document}
Notice ...
$ /usr/bin/python -V
Python 2.3.5
... but ...
$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python
$ `which python` --version
Python 2.5
Then, output from lilypond-book 2.11.43 under OS X 10.4.11:
$ lilypond-book --pdf --out=out test.tex
lilypond-book (GNU LilyPond) 2.11.43
Reading test.tex...
Running latex...This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%-line parsing enabled.
entering extended mode
(/tmp/tmpvQnECb.tex
LaTeX2e 2005/12/01
Babel v3.8h and hyphenation patterns for english, usenglishmax, dumylang,
noh
yphenation, arabic, basque, bulgarian, coptic, welsh, czech, slovak, german,
ng
erman, danish, esperanto, spanish, catalan, galician, estonian, farsi,
finnish,
french, greek, monogreek, ancientgreek, croatian, hungarian, interlingua,
ibyc
us, indonesian, icelandic, italian, latin, mongolian, dutch, norsk, polish,
por
tuguese, pinyin, romanian, russian, slovenian, uppersorbian, serbian,
swedish,
turkish, ukenglish, ukrainian, loaded.
(/usr/local/texlive/2007/texmf-dist/tex/latex/base/article.cls
Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
(/usr/local/texlive/2007/texmf-dist/tex/latex/base/size10.clo))
No file tmpvQnECb.aux.
textwidth=345.0pt
columnsep=10.0pt
(./tmpvQnECb.aux) )
No pages of output.
Transcript written on tmpvQnECb.log.
Dissecting...
Traceback (most recent call last):
File /Applications/LilyPond.app/Contents/Resources/bin/lilypond-book,
line 1930, in ?
main ()
File /Applications/LilyPond.app/Contents/Resources/bin/lilypond-book,
line 1912, in main
chunks = do_file (files[0])
File /Applications/LilyPond.app/Contents/Resources/bin/lilypond-book,
line 1821, in do_file
do_process_cmd (chunks, input_fullname, global_options)
File /Applications/LilyPond.app/Contents/Resources/bin/lilypond-book,
line 1657, in do_process_cmd
output_files = set(os.listdir(options.lily_output_dir))
NameError: global name 'set' is not defined
Adding ...
import md5
import os
import re
import stat
import sys
import tempfile
from sets import Set as set # new line 37
...enables python 2.3.5 to reference the set constructor globally.
HTH. Not exactly the same problem Graham was reporting, but perhaps related.
Trevor.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: lilypond-book 2.11.43 broken
On Sun, Apr 13, 2008 at 4:03 PM, Graham Percival [EMAIL PROTECTED] wrote: On Sun, 13 Apr 2008 12:48:16 -0500 Trevor Ba__a [EMAIL PROTECTED] wrote: HTH. Not exactly the same problem Graham was reporting, but perhaps related. No, this *is* exactly the same problem. As a follow-up, I sent an email to -devel about usr/bin/env python (or something like that). Edit lilypond-book (inside the LilyPond.app package) and replace #!/usr/bin/python with #!/usr/bin/env python That will use the python in your path. Ah right. Of course! Thanks, Graham. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug: nested alist accessor syntax broken for TextSpanner #'bound-details #'[left, right]-broken
2008/2/8 Valentin Villenave [EMAIL PROTECTED]: On 07/02/2008, Trevor Bača [EMAIL PROTECTED] wrote: Hi Valentin, Another one for the tracker. I suspect this one relates very closely to the previous bug I mailed in less than an hour ago, but I'm not certain. Maybe add to the tracker as two separate IDs, but referencing each other? Either way, these two mail given info that should wind up as two separate regression tests once a fix shows up later on. Hmm... What I did was to rename the 576 issue, and include your new report as a comment: http://code.google.com/p/lilypond/issues/detail?id=576 ...because this seems too closely related to be regarded as a new bug (IMO). Anyway, thanks a lot for having investigated this; I'm precisely working on the GDP Text section and maybe I'm gonna use some help with TextSpanners :) OK, cool. I build a lot of text spanners, so poke me when you get there and I'll go back through my notes and see if maybe I can help. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Bug: score-final mark mangles score-final tuplet bracket
On Feb 4, 2008 7:10 PM, Trevor Bača [EMAIL PROTECTED] wrote:
Hi Valentin,
Could you please consider this one for the tracker? It's quite specific
thing ever, but highly reproducible (and quite irritating).
===
The score-final mark badly mangles the score-final tuplet bracket in the
snippet below:
%%% BEGIN MANGLE %%%
\version 2.11.34
\new Staff {
\set tupletFullLength = ##t
\time 1/8
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\override Score.RehearsalMark #'break-visibility = ##(#t #t #t)
\override Score.RehearsalMark #'direction = #down
\override Score.RehearsalMark #'break-align-symbol = #'clef
\override Score.RehearsalMark #'self-alignment-X = #right
\mark Composed Feb 2007 - Feb 2008
}
%%% END %%%
FWIW, you do seem to need all five settings above to induce the problem.
(Actually, mark direction can be either up or down, but appears more clearly
with the mark set down.)
Oops. Here's a pic of the resulting output.
--
Trevor Bača
[EMAIL PROTECTED]
attachment: mangled-bracket.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Bug: score-final mark mangles score-final tuplet bracket
Hi Valentin,
Could you please consider this one for the tracker? It's quite specific
thing ever, but highly reproducible (and quite irritating).
===
The score-final mark badly mangles the score-final tuplet bracket in the
snippet below:
%%% BEGIN MANGLE %%%
\version 2.11.34
\new Staff {
\set tupletFullLength = ##t
\time 1/8
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\times 2/3 { c'16 c'16 c'16 }
\override Score.RehearsalMark #'break-visibility = ##(#t #t #t)
\override Score.RehearsalMark #'direction = #down
\override Score.RehearsalMark #'break-align-symbol = #'clef
\override Score.RehearsalMark #'self-alignment-X = #right
\mark Composed Feb 2007 - Feb 2008
}
%%% END %%%
FWIW, you do seem to need all five settings above to induce the problem.
(Actually, mark direction can be either up or down, but appears more clearly
with the mark set down.)
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.11.30 segmentation fault
On 9/2/07, Nicolas Sceaux [EMAIL PROTECTED] wrote: Han-Wen Nienhuys [EMAIL PROTECTED] writes: Joe Neeman escreveu: On Saturday 01 September 2007 09:00, Trevor Bača wrote: On 8/31/07, Joe Neeman [EMAIL PROTECTED] wrote: On Friday 31 August 2007 23:17, Trevor Bača wrote: Should I send the inputfile to either Joe or Han-Wen for testing against .31? I'd be happy to take a look at it. Thank you *so* much, Joe! Will send offlist ... I can't reproduce with git or the x86-linux binary. I get a segfault with the amd64 binary... in ghostscript (during the convert-to-pdf stage). If I take the .ps file and run it though the system's ghostscript, it works perfectly. So it seems to be a problem with the ghostscript that's included in the binary package. In the original report, it didn't crash in GS but in lily. It looks as if someone needs to build a macos binary without stripping. I have such a beast here, maybe Trevor could send me his failing file. Excellent! I'll send you the file offlist in just a second ... and you can feed it to the beast ;-) -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.11.30 segmentation fault
On 8/31/07, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: 2007/8/31, Trevor Bača [EMAIL PROTECTED]: Hi, Crossposted as Google #433. Running 2.11.30 on a relatively large file (110 measures of six staves with 4559 lines of total input) causes the following segmentation fault. GNU LilyPond 2.11.30 Processing `/Users/trevorbaca/Documents/lilypond/pictures/1768.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects.../Users/trevorbaca/Documents/lascaux/scr/lily: line 4: 14270 Segmentation fault I've been cutting out parts of the file all morning to produce a minimal snippet. But at this point it appears that the seg fault comes from the *size* of the inputfile rather than from the *musical contents*. (Ie, file compiles absolutely fine to and with measure 109; adding measure 110 *in any of the six musical staves* causes the seg fault.) One way of finding this out is to run the thing inside GDB and look at the stack trace. Unfortunately, for useful information, you have to do this in an unstripped binary, which is not included in the installer. Joe's looking at the inputfile, which is awesome. For future reference, is there any way to get an unstripped binary (one with all the debug messages not commented out, right?) from the website? Or is git the only way to go? (I've so far avoided using git because I've not been contributing patches; but I'm certainly comfortable running stuff in gdb if it would help.) -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Strange cross-stave beam and slur behaviour with portato
On 9/1/07, Neil Puttock [EMAIL PROTECTED] wrote:
Hello,
The portato sign is causing some strange behaviour with both beams and slurs
when a voice crosses staves.
Unfortunately, I can't seem to replicate the beaming problem in a minimal
example, but it seems related to the following snippet where the portato
mark causes the slur to be skewed:
\version 2.11.30
\paper { ragged-right = ##t }
lh = \change Staff = lh
rh = \change Staff = rh
\score {
\new PianoStaff
\new Staff = rh \relative { c8-_( \lh \stemDown e[ c g]) }
\new Staff = lh { \clef bass s4. }
}
Hi Neil,
I can't be certain, but I'd bet that this is related to Google #430:
http://code.google.com/p/lilypond/issues/detail?id=430
If it's the same bug, then we're in luck because Han-Wen and Joe have
marked #430 fixed in the upcoming 2.11.32 build.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
2.11.30 segmentation fault
Hi, Crossposted as Google #433. Running 2.11.30 on a relatively large file (110 measures of six staves with 4559 lines of total input) causes the following segmentation fault. GNU LilyPond 2.11.30 Processing `/Users/trevorbaca/Documents/lilypond/pictures/1768.ly' Parsing... Interpreting music... [8][16][24] Preprocessing graphical objects.../Users/trevorbaca/Documents/lascaux/scr/lily: line 4: 14270 Segmentation fault I've been cutting out parts of the file all morning to produce a minimal snippet. But at this point it appears that the seg fault comes from the *size* of the inputfile rather than from the *musical contents*. (Ie, file compiles absolutely fine to and with measure 109; adding measure 110 *in any of the six musical staves* causes the seg fault.) Should I send the inputfile to either Joe or Han-Wen for testing against .31? (Note: not related to Google #430 which Han-Wen has already fixed.) -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.11.30 segmentation fault
On 8/31/07, Valentin Villenave [EMAIL PROTECTED] wrote: 2007/8/31, Trevor Bača [EMAIL PROTECTED]: Hi, Crossposted as Google #433. Hi Trevor, I don't know if you've suscribed to the bug-lilypond list (if you have not, I can tell you it is very interesting), but it seems that each issue posted on Google (and each comment, or attribute changes) is forwarded to the bug- list; so I don't think you have to cross-post anymore. (the opposite is not true: a mail to bug- won't be forwarded to the google tracker, unless some generous soul adds it). OK, very good. I am subscribed to bug-. But I thought that I received forwarded copies of the bugs I opened because I opened them (rather than because everything forwards to bug-). Good to know. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.11.30 segmentation fault
On 8/31/07, Joe Neeman [EMAIL PROTECTED] wrote: On Friday 31 August 2007 23:17, Trevor Bača wrote: Should I send the inputfile to either Joe or Han-Wen for testing against .31? I'd be happy to take a look at it. Thank you *so* much, Joe! Will send offlist ... Trevor. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Cross-staff beam craziness (when down-markup combines with down-articulation)
Hi,
Crossposted as Google #430.
This one was really, really nasty to find.
In the following snippet we need the whole witches' brew of settings to
cause the bug (but it's quite repeatable). Specifically, the combination of
BOTH the down-markup AND the down-articulation TOGETHER WITH the
staff-changing note causes stemming and beaming to completely screw up.
Commenting out EITHER the down-markup OR the down-articulation OR BOTH
causes the stemming and beaming to work perfectly.
Bug shows up in both .29 and .30 but I haven't tested earlier builds to see
when exactly it entered.
%%% BEGIN %%%
\version 2.11.30
\new PianoStaff
\new Staff = RH {
\time 1/4
c''16 [
c''16
\change Staff = LH
c''16 \tenuto _ \markup { foo }
\change Staff = RH
c''16 ]
}
\new Staff = LH {
s4
}
%%% END %%%
Really nasty is some heavily \markup-ed piano music.
--
Trevor Bača
[EMAIL PROTECTED]
attachment: stemming-and-beaming-craziness.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
2.11.30: ... (ly:font-load aybabtu): font.scm:175:29: #unknown port:138:24: missing close paren
2.11.30 generates the following fatal error (entered as Google #419):
GNU LilyPond 2.11.30
Processing `0174.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing
systems.../Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/font.scm:175:29:
In procedure scm_lreadrecparen in expression (ly:font-load aybabtu):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/font.scm:175:29:
#unknown port:138:24: missing close paren
The inputfile is this:
%%% BEGIN %%%
\version 2.11.30
\new Score
\new Violin
\new ViolinPitches c'4
\new Bow c'4
\layout {
\context { \Staff
\type Engraver_group
\name ViolinPitches
\alias Staff
}
\context { \RhythmicStaff
\type Engraver_group
\name Bow
\alias Staff
}
\context { \GrandStaff
\name Violin
\alias GrandStaff
\accepts ViolinPitches
\accepts Bow
}
\context { \Score
\accepts Violin
}
}
%%% END %%%
Note that 2.11.29 compiles with no errors at all.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.11.30: ... (ly:font-load aybabtu): font.scm:175:29: #unknown port:138:24: missing close paren
On 8/21/07, Trevor Bača [EMAIL PROTECTED] wrote:
2.11.30 generates the following fatal error (entered as Google #419):
GNU LilyPond 2.11.30
Processing `0174.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing
systems.../Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/font.scm:175:29:
In procedure scm_lreadrecparen in expression (ly:font-load aybabtu):
/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/scm/font.scm:175:29:
#unknown port:138:24: missing close paren
The inputfile is this:
%%% BEGIN %%%
\version 2.11.30
\new Score
\new Violin
\new ViolinPitches c'4
\new Bow c'4
\layout {
\context { \Staff
\type Engraver_group
\name ViolinPitches
\alias Staff
}
\context { \RhythmicStaff
\type Engraver_group
\name Bow
\alias Staff
}
\context { \GrandStaff
\name Violin
\alias GrandStaff
\accepts ViolinPitches
\accepts Bow
}
\context { \Score
\accepts Violin
}
}
%%% END %%%
Note that 2.11.29 compiles with no errors at all.
Brace drawing is the problem. If anyone's got PianoStaff (or
GrandStaff) music in .30, the same error will result.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Hairpin through piano staff change causes explosions
Hi,
Entered as Google #141, the following snippet explodes because of the
hairpin at line 7:
%%% EX 1 %%%
\version 2.11.28
\new PianoStaff
\new Staff = pianoone {
\time 3/4
c'''16 \mp
\
c'''16
c'''16
r16
\change Staff = pianotwo
c16
c16
c16
r16
\change Staff = pianoone
c'''16
c'''16
c'''16 \mf
r16
}
\new Staff = pianotwo {
\clef bass
\time 3/4
s2.
}
%%% END EX 1 %%%
GNU LilyPond 2.11.28
Processing `0165.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...ERROR: In procedure
ly:hara-kiri-group-spanner::pure-height:
ERROR: Wrong type argument in position 2: 0
rm: 0165.ps: No such file or directory
Commenting out the hairpin \ at line 7 produces the otherwise correct
output attached here.
--
Trevor Bača
[EMAIL PROTECTED]
attachment: hairpin-explosions.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Hairpin through piano staff change causes explosions
On 8/18/07, Trevor Bača [EMAIL PROTECTED] wrote:
Hi,
Entered as Google #141, the following snippet explodes because of the
hairpin at line 7:
%%% EX 1 %%%
\version 2.11.28
\new PianoStaff
\new Staff = pianoone {
\time 3/4
c'''16 \mp
\
c'''16
c'''16
r16
\change Staff = pianotwo
c16
c16
c16
r16
\change Staff = pianoone
c'''16
c'''16
c'''16 \mf
r16
}
\new Staff = pianotwo {
\clef bass
\time 3/4
s2.
}
%%% END EX 1 %%%
GNU LilyPond 2.11.28
Processing `0165.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...ERROR: In procedure
ly:hara-kiri-group-spanner::pure-height:
ERROR: Wrong type argument in position 2: 0
rm: 0165.ps: No such file or directory
Commenting out the hairpin \ at line 7 produces the otherwise correct
output attached here.
ACK; I reported against .28.
Fixed in .29, as the attached png shows.
Please disregard and close Google #414.
--
Trevor Bača
[EMAIL PROTECTED]
attachment: hairpin-correct.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Tuplet bracket sometimes not printed
On 8/1/07, Graham Percival [EMAIL PROTECTED] wrote:
Thanks for this report.
Trevor, is there any special tuplet property to say always print a
bracket? I thought there was, but I can't see it.
If there isn't such a property, I'll add this to the bug tracker.
Sure: it's the bracket-visibility attribute; compare below:
%%% BRACKET-VISIBILITY %%%
\version 2.11.27
\new RhythmicStaff {
\times 2/3 {
c'8 c'8 c'8
}
\override TupletBracket #'bracket-visibility = ##t
\times 2/3 {
c'8 c'8 c'8
}
}
%%% END %%%
I tried setting bracket-visibility = ##t in Tuukka's example but still
there is no bracket under the second figure. I've always corrected
this sort of thing by simply adding more spacing (usually by using
proportional notation). But I think I agree that it's bug and that
lily should at least print a very very small bracket in this case.
Tuukka Verho wrote:
HI all,
Lilypond 2.11.28 seems to omit the tuplet bracket if the horizontal space
taken by the tuplet is very small. This can happen if the tuplet consists of
an eight rest and a quarter note with the stem down. A minimal example is
shown below. There are three very similar tuplets, the first and the last of
which are printed correctly. The middle one, however, has a quarter note
with
the stem down and the bracket is missing.
\version 2.11.28
% If ragged-right = ##f, the music is spaced more broadly and the bug
% doesn't occur.
\paper {
ragged-right = ##t
}
% The bracket for the middle tuplet won't be printed
\relative c' {
\times 2/3 {r8 c4} \times 2/3 {r8 c'4} \times 2/3 {r8 c c}
}
Kind regards,
Tuukka Verho
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
404s for the 2.11 docs
Hi, The 2.11 user manual, reference manual and snippets have all been giving 404s for the last couple of hours. I assumed this was due to a doc (re)building process going on somewhere. But if not, could someone put the docs back online? Trevor. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Line-breaking causes one case of beam insanity
Opened as Google #393 (http://code.google.com/p/lilypond/issues/detail?id=393):
The snippet below should print two identical measures of 5/64 beamed
together with a single spanning beam. Instead, the nibs of the first
64th note extend incorrectly all the way to the line break.
%%% EX 1 %%%
\version 2.11.26
\layout { ragged-right = ##t }
\new Staff {
\override Beam #'breakable = ##t
\time 5/64
c'64 [
\set stemLeftBeamCount = #2
\set stemRightBeamCount = #1
c'16
\break
\set stemLeftBeamCount = #1
\set stemRightBeamCount = #4
c'64
c'16 ]
}
%%% EX 1 %%%
Not sure which version this showed up in but I think it's been around for a
while.
--
Trevor Bača
[EMAIL PROTECTED]
attachment: beam-insanity.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Kinda nasty allocation error
to debug terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc /Users/trevorbaca/Documents/lascaux/scr/lily: line 4: 481 Abort trap %%% The error isn't critical to me because the file is a sketch only, not a production score. But if anyone wants to take a look at the inputfile, let me know and I'll mail separately. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
Hi, Do we need to worry about this programming error? I was interpreting a gigantic inputfile (65,000 lines) but the output turned out just fine. Here's the complete output of the run (which is quite clean except for the one error), running under OS X: GNU LilyPond 2.11.26 Processing `1083.ly' Parsing... Interpreting music... [8][16][24][32][40][48][56] Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 55 or 56 pages... Drawing systems... Layout output to `1083.ps'... Converting to `1083.pdf'... programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers I can send over the complete inputfile if anyone cares; but, again, the output is just fine. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*)
I wouldn't bother; output is fine. On 7/3/07, Graham Percival [EMAIL PROTECTED] wrote: No, we don't worry about programming errors. We produce too many false warning messages to bother fixing them. If it's a first-time bug reporter, I'll faithfully add it to the tracker, but they get the lowest priority. Cheers, - Graham Trevor Bača wrote: Hi, Do we need to worry about this programming error? I was interpreting a gigantic inputfile (65,000 lines) but the output turned out just fine. Here's the complete output of the run (which is quite clean except for the one error), running under OS X: GNU LilyPond 2.11.26 Processing `1083.ly' Parsing... Interpreting music... [8][16][24][32][40][48][56] Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 55 or 56 pages... Drawing systems... Layout output to `1083.ps'... Converting to `1083.pdf'... programming error: Parsed object should be dead: static scm_unused_struct* Prob::mark_smob(scm_unused_struct*) continuing, cross fingers I can send over the complete inputfile if anyone cares; but, again, the output is just fine. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Text spanners don't display beginning/ending text in 2.11.25
Hi Nathan,
Try running convert-ly; #'edge-text was replaced by a different
construct in about .12 or .13 ...
Trevor.
On 5/28/07, Nathan Reed [EMAIL PROTECTED] wrote:
\version 2.11.25
\paper { ragged-right = ##t }
\relative c'{
\override TextSpanner #'edge-text = #'(start . end)
c1\startTextSpan
c1\stopTextSpan
}
The start and end text does not appear, only the dotted line. This bug
appeared in 2.11.25, but was not present in 2.11.23.
Thanks,
Nathan Reed
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: mensural barlines
On 5/16/07, karim haddad [EMAIL PROTECTED] wrote:
Hi another issue
in former version 2.11.20
using \override BarLine #'transparent = ##t
with a StaffGroup used to work.
now with the latest version 2.11.23-1 this doesn;t seem to work anymore
any ideas ??
Hi Karim,
Are you sure you've got the \override in the right context? The
BarLine grob lives in the Score context (and not the Staff or Voice
contexts). So ...
%%% BEGIN %%%
\version 2.11.22
\new Staff {
\override Score.BarLine #'transparent = ##t
c'1 c'1 c'1 c'1
}
%%% END %%%
... works while this one ...
%%% BEGIN %%%
\version 2.11.22
\new Staff {
\override BarLine #'transparent = ##t
c'1 c'1 c'1 c'1
}
%%% END %%%
... doesn't.
Maybe that's why?
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Fwd: mensural barlines
On 5/16/07, karim haddad [EMAIL PROTECTED] wrote:
karim haddad wrote:
Begin forwarded message:
*From: *Trevor Bača [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
*Date: *May 16, 2007 5:59:42 PM CEDT
*To: *karim haddad [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
*Cc: [EMAIL PROTECTED] mailto:bug-lilypond@gnu.org
*Subject: **Re: mensural barlines*
On 5/16/07, karim haddad [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi another issue
in former version 2.11.20
using \override BarLine #'transparent = ##t
with a StaffGroup used to work.
now with the latest version 2.11.23-1 this doesn;t seem to work anymore
any ideas ??
Hi Karim,
Are you sure you've got the \override in the right context? The
BarLine grob lives in the Score context (and not the Staff or Voice
contexts). So ...
%%% BEGIN %%%
\version 2.11.22
\new Staff {
\override Score.BarLine #'transparent = ##t
c'1 c'1 c'1 c'1
}
%%% END %%%
... works while this one ...
%%% BEGIN %%%
\version 2.11.22
\new Staff {
\override BarLine #'transparent = ##t
c'1 c'1 c'1 c'1
}
%%% END %%%
... doesn't.
Maybe that's why?
--
Trevor Bača
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Hi Trevor
Thanx for your reply.
But in fact it was indeed in the \layout {\context {\Score.
However i tried it to put it directly as you have proposed but without
result.
And by the way it works fine with version 2.11.22 but not in the 2.11.23
( i am using the Linux x86 version).
Hi Karim,
Hmm; Maybe it's an issue in the Linux build? I just downloaded 2.11.23
and it works fine with the following snippet ...
%%% BEGIN %%%
\version 2.11.23
\new Staff {
\override Score.BarLine #'transparent = ##t
c'1
c'1
c'1
}
%%% END %%%
... which produces the output attached.
This is all on an OS X Mac, though, which is why I'm guessing it's
maybe a Linux issue?
Can you send the example minimal fragment you're trying on Linux and
I'll compile under OS X?
--
Trevor Bača
[EMAIL PROTECTED]
attachment: barline.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: incompatible stem (type = 16)
On 3/15/07, karim haddad [EMAIL PROTECTED] wrote: Hello list In this .ly file (very unconventional) i have a problem with : /Users/hyperion/Desktop/lilbug/6.ly:72:0: warning: adding note head to incompatible stem (type = 16) c'1*4/21~ although c'1 is a whole note and should has no stem Even weirder, this works with the 2.10 version which reports the error, but in the latest version 2.11.20-1 i have the error and lilypond just hangs... Hi Karim, OK, that's really odd. I use the multiplication operator for time scaling a lot, too, and I've never run into that particular error. Trevor. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 'fermata'
On 3/3/07, Paul Scott [EMAIL PROTECTED] wrote: Graham Percival wrote: (snip) As a Canadian, I'm mortified to find myself agreeing with the Yanks :P , but that is the case. I've never heard of a pause being used in a formal sense; it's always been used when addressing children or inexperienced amateur musicians. Still, the purpose of the glossary is to educate such people (I'm now including the whole UK and their penal colony as inexperienced :), so I've added pause to the glossary. :) The other American English word I'm familiar with for fermata is hold. ? I'm confused. Hold -- like pause -- certainly isn't used as a musical term in the US. Or am I missing something? Is hold a Britishism for fermata? -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Analysis brackets
On 2/16/07, D. Stoltz [EMAIL PROTECTED] wrote: Hi, may it be possible that the analysis brackets options do not work at all? I tried to use straight brackets representing slurs in renaissance music - but the bracket-flare parameter seemed to have no effect on the brackets. - Thanks in advance for any help you might offer! Please send a short example. Chances are good you're overriding the wrong grob, or overriding the right grob in the wrong context. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Rehearsal mark appears on wrong staff
Hi Graham,
Definitely a bug. line-break-system-details shouldn't cause the mark
to switch staves.
Could you open in Google?
Trevor.
On 2/12/07, Graham Percival [EMAIL PROTECTED] wrote:
Trevor, could you take a look at this? If I remove the spacing
weirdness, the rehearsal mark is created on the right staff. Do you
know what's happening? Is this a good example for the bug tracker?
Cheers,
- Graham
Daniel Johnson wrote:
Sorry, the previous example should have been:
% BEGIN
\version 2.11.17
spaceWide = {
\overrideProperty #Score.NonMusicalPaperColumn
#'line-break-system-details
#'((alignment-offsets . ( 0 -80 )))
}
\score {
\new Staff { \spaceWide c''1 | \break \spaceWide c''1 | c''1 | \break
\spaceWide c''1 | }
\new Staff \with { \consists Mark_engraver } { g' | g'\mark lower
staff | g' | g' | }
\layout { \context { \Score \remove Mark_engraver } }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: warning: Can't fit systems on page -- ignoring between-system-padding
On 2/13/07, Joe Neeman [EMAIL PROTECTED] wrote:
On 2/12/07, Trevor Bača [EMAIL PROTECTED] wrote:
Hi,
Pretty sure this is a bug, but thought I'd post to bug- first before
opening in Google.
Sometimes I build .ly files that are essentially text docs as a
sequence of \markup commands.
In versions up to the .11 dev series, what we might call multipage
markup files would of course break onto multiple pages if there were
enough \markup blocks to warrant so.
In the current releases a warning issues and all the text gets shoved
onto a single page, even if there's a considerable amount of text and
overprint results.
%%% BEGIN %%%
\version 2.11.17
\markup { text. }
snip
\markup { text. }
%%% END %%%
Sorry for the length of the example; needs length to show up.
Bug? Or new behavior? (If the latter, what's the right way to set a page
break?)
Bug. It also raises the problem of how to force or forbid a page break
between markup blocks. The backend supports it, but we don't have a
way to actually specify it in the input file.
Reall? That's cool. I've wanted something like that for quite some
time when I put together what essentially text docs in .ly files.
Could we simply allow \pageBreak to float in the middle of a file, I
guess at top level?
%%% BEGIN %%%
\markup \wordwrap { lots and lots of text ... }
\pageBreak
\markup \wordwrap { more and more text ... }
%%% END %%%
Crowded markup stuff added as Google 293.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Erratic Scores... Lilypond 2.11.16 / 2.11.17 Windows
On 2/12/07, Paul Scott [EMAIL PROTECTED] wrote: Trent Johnston wrote: Hi Everyone, I don't know if anyone else has similar problems but 2.11.16 and 2.11.17 with the automatic staff stretching I'm getting strange results... most of my scores end up compiling with... warning: Can't fit systems on page -- ignoring between-system-padding my between-system-padding is set a small 1... I am having the same problem. I can make a small change and get a segfault and then change it a little differently and get output. I get those messages either way. Hi, Pretty sure this is a recent bug. May also relate to http://lists.gnu.org/archive/html/bug-lilypond/2007-02/msg00163.html Moving thread over to bug-. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
warning: Can't fit systems on page -- ignoring between-system-padding
Hi,
Pretty sure this is a bug, but thought I'd post to bug- first before
opening in Google.
Sometimes I build .ly files that are essentially text docs as a
sequence of \markup commands.
In versions up to the .11 dev series, what we might call multipage
markup files would of course break onto multiple pages if there were
enough \markup blocks to warrant so.
In the current releases a warning issues and all the text gets shoved
onto a single page, even if there's a considerable amount of text and
overprint results.
%%% BEGIN %%%
\version 2.11.17
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
\markup { text. }
%%% END %%%
Sorry for the length of the example; needs length to show up.
Bug? Or new behavior? (If the latter, what's the right way to set a page break?)
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: bug edge-height in 2.11.15
On 2/2/07, Martial [EMAIL PROTECTED] wrote:
In version 2.11.15, ( as in the 2.11.14)
the bracket won't be vertical with TextSpanner #'edge-height.
No bug in 2.10.14, 2.10.15. and 2.11.13
%%---Edge-Height-bug
\version 2.11.15
\relative {
\once \override TextSpanner #'dash-fraction = #'()
\once \override TextSpanner #'edge-height = #'(2 . 0)
\once \override TextSpanner #'padding = #3
c\startTextSpan e g\stopTextSpan
}
%%- END
Hi Martial,
TextSpanners have been changing in the 2.11.x releases and I think I
saw a convert-ly rule for edge-height in 2.11.15. The last conversion
in python/convertrules.py looks like
#'bound-details #'left (or #'right) = \markup { \draw-line #'(0 . whatever) }
may be the way to go.
Alternatively, try running convert-ly on an older file with the older
edge-height syntax.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
centered-on-x-parent gone temporarily insane?
Hi,
What's going on here?
%%% BEGIN %%%
\version 2.11.15
\new Staff {
\override TextScript #'X-offset =
#(ly:make-simple-closure
`(,+ ,(ly:make-simple-closure (list
ly:self-alignment-interface::x-aligned-on-self))
,(ly:make-simple-closure (list
ly:self-alignment-interface::centered-on-x-parent
\override TextScript #'self-alignment-X = #left
c'4_\markup { MMM }
\override TextScript #'self-alignment-X = #center
c'4_\markup { MMM }
\override TextScript #'self-alignment-X = #right
c'4_\markup { MMM }
}
%%% END %%%
The overrides to self-alignment-X cause all three pieces of text to go
to *really* weird places.
Has the syntax for x-centering on parent changed again? Or am I
forgetting something?
(FWIW, the override to X-offset above comes from the definition of
OctavateEight in define-grobs.scm; see
http://lists.gnu.org/archive/html/lilypond-user/2006-09/msg00088.html.)
--
Trevor Bača
[EMAIL PROTECTED]
x-center.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Flageolet position shifts according to beam status?
Hi,
Can someone please render the following and tell me whether I'm going blind?
The example includes two scores. The scores differ only in the fact
that the first score beams all notes together while the second score
beams no notes. It looks like the flageolets in the second score are
shifted ever so slightly off-center towards the *right*.
Can someone else confirm that this seems to be the case before I post
the nitpick in the bug tracker?
%%% BEGIN OFF-CENTER FLAGEOLET? %%%
\override NoteHead #'font-size = #-3
\override Accidental #'font-size = #-3
\override Script #'font-size = #-3
\override Script #'padding = #0.5
d'''64 [ \flageolet
fs'''64 \flageolet
a'''64 \flageolet
c64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 ] \flageolet
\revert NoteHead #'font-size
\revert Accidental #'font-size
\revert Script #'font-size
\revert Script #'padding
}
\new Staff {
\override NoteHead #'font-size = #-3
\override Accidental #'font-size = #-3
\override Script #'font-size = #-3
\override Script #'padding = #0.5
d'''64 \flageolet
fs'''64 \flageolet
a'''64 \flageolet
c64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
\revert NoteHead #'font-size
\revert Accidental #'font-size
\revert Script #'font-size
\revert Script #'padding
}
%%% END %%%
(In fact, it may be that the first score shifts flageolets ever so
slightly to the *left* while the second score shifts flageolets ever
so slightly to the *right*? FWIW, commenting out the overrides seems
to center all flageolets exactly on the noteheads, as expected.)
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Flageolet position shifts according to beam status?
On 1/25/07, Mats Bengtsson [EMAIL PROTECTED] wrote:
I would recommend to use
\set fontSize = #-3
instead of
\override NoteHead #'font-size = #-3
\override Accidental #'font-size = #-3
\override Script #'font-size = #-3
As far as I can see, the result doesn't give any extra shift, whereas I
might guess that there is a slight shift when using your original code.
/Mats
Trevor Bača wrote:
Hi,
Can someone please render the following and tell me whether I'm going
blind?
The example includes two scores. The scores differ only in the fact
that the first score beams all notes together while the second score
beams no notes. It looks like the flageolets in the second score are
shifted ever so slightly off-center towards the *right*.
Can someone else confirm that this seems to be the case before I post
the nitpick in the bug tracker?
%%% BEGIN OFF-CENTER FLAGEOLET? %%%
\override NoteHead #'font-size = #-3
\override Accidental #'font-size = #-3
\override Script #'font-size = #-3
\override Script #'padding = #0.5
d'''64 [ \flageolet
fs'''64 \flageolet
a'''64 \flageolet
c64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 ] \flageolet
\revert NoteHead #'font-size
\revert Accidental #'font-size
\revert Script #'font-size
\revert Script #'padding
}
\new Staff {
\override NoteHead #'font-size = #-3
\override Accidental #'font-size = #-3
\override Script #'font-size = #-3
\override Script #'padding = #0.5
d'''64 \flageolet
fs'''64 \flageolet
a'''64 \flageolet
c64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
d64 \flageolet
e64 \flageolet
fs64 \flageolet
e64 \flageolet
\revert NoteHead #'font-size
\revert Accidental #'font-size
\revert Script #'font-size
\revert Script #'padding
}
%%% END %%%
(In fact, it may be that the first score shifts flageolets ever so
slightly to the *left* while the second score shifts flageolets ever
so slightly to the *right*? FWIW, commenting out the overrides seems
to center all flageolets exactly on the noteheads, as expected.)
Hm, fontSize does seem to clean things up a bit. The flageolets still
look imperfectly centered, IMO, but it's such a fine difference as to
not warrant the time for a fix ...
Thanks, Mats.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Google issues 204, 205, 206 duplicate - please collapse
Hi Graham, Could you collapse Google issue numbers 204, 205, 206 into a single ID? I tried attaching a file (12k .png) and Google twice timed out, gave a server error, and said try again. So I did. But in fact each click of the submit button duplicated the issue (still without the attachment). Is there some rule about non-project members not being able to attach files? -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: BUS ERROR: strict-note-spacing together with \afterGrace
On 12/17/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Trevor Bača escreveu:
Hi,
Setting SpacingSpanner #'strict-note-spacing = ##t together with
\afterGrace causes a bus error.
http://code.google.com/p/lilypond/issues/detail?id=176
(Tried responding directly on the issue-tracking pages, but I'm not
sure if the changes took; so crossposting here.)
The issue-tracking page says to use \new Voice. But using \new Voice
causes another bus error.
%%% BEGIN %%%
\version 2.11.2
\new Staff
\override Score.SpacingSpanner #'strict-note-spacing = ##t % Also
causes a bus error
\new Voice {
s8
s8
\afterGrace s8 { c'32 [ c'32 c'32 c'32 ] }
s8
}
\new Voice {
\override Stem #'direction = #down
c'8 [
c'8
c'8
c'8 ]
}
%%% END %%%
Am I using the wrong voice instantiation syntax? Could you provide a
small snippet showing the correct syntax for this example?
(The goal is like the png attached to this mail, except with
strict-note-spacing turned on.)
--
Trevor Bača
[EMAIL PROTECTED]
afterGrace.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: BUS ERROR: strict-note-spacing together with \afterGrace
On 12/16/06, Trevor Bača [EMAIL PROTECTED] wrote:
Hi,
Setting SpacingSpanner #'strict-note-spacing = ##t together with
\afterGrace causes a bus error.
%%% BEGIN %%%
\version 2.11.2
\new Staff {
\override Score.SpacingSpanner #'strict-note-spacing = ##t % CAUSES BUS ERROR
\afterGrace c'4 {c'32 [ c'32 c'32 c'32 ]}
c'4
c'4
c'4
}
%%% END %%%
Severe (and no workaround seems to exist).
There is one exact condition necessary to trigger this bus error: the
\afterGrace must be the very first event in the context.
So the dummy note below prevents the following example from failing:
%%% NO LONGER FAILS %%%
\version 2.11.2
\new Staff {
\override Score.SpacingSpanner #'strict-note-spacing = ##t % CAUSES BUS ERROR
c'4 % NO LONGER FAILS BECAUSE afterGrace NO LONGER INITIAL
\afterGrace c'4 {c'32[ c'32 c'32 c'32]}
c'4
c'4
}
%%% END %%%
Bus error also obtains with strict-grace-spacing (in addition to
strict-note-spacing):
%%% BEGIN SECOND BUS ERROR %%%
\version 2.11.2
\new Staff {
\override Score.SpacingSpanner #'strict-grace-spacing = ##t %
CAUSES BUS ERROR
\afterGrace c'4 {c'32[ c'32 c'32 c'32]}
c'4
c'4
c'4
}
%%% END %%%
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Unexpected tuplet bracket location
On 11/14/06, Victor Eijkhout [EMAIL PROTECTED] wrote:
I'd call it a bug that the tuplet bracket jumps up and down even
though the pitch doesn't change.
Btw, sometimes the bracket completely disappears, but I haven't been
able to make a small example with that.
quartertriplet = { \set tupletSpannerDuration = #(ly:make-moment 1 4) }
\relative { \time 3/4 \clef treble \key g \minor
\relative c'' {
\quartertriplet
\times 2/3 { r8 a r a r4} r4 | r8 g r g r4 |
\times 2/3 { r8 a r a r4} r4 | r8 bes r bes r4 |
\times 2/3 { r8 c r c r4} r4 | r8 bes r bes r4 |
\times 2/3 { r8 a r a r a} r8 a | r4. g |
}
}
\version 2.9.27
Same output with 2.9.something and 2.10.
Hi Victor,
With regards to the disappearing tuplet bracket, is it possible that
the bracket goes away when the enclosed figure beams completely? By
default, Lily will print only a TupletNumber (and not a TupletBracket)
when the enclosed music beams completely.
You can force the TupletBracket to print with
\once \override TupletBracket #'bracket-visibility = ##t
immediately before any \times statement. If you always want to force
TupletBrackets in all places, include the \override (minus the \once)
in the \with block of your current context (Voice, Staff, Score or
whatever).
As far as the 'jumping' brackets in the example, it looks like Lily
determines the tuplet bracket position (either up or down) based on
the stem direction of the first note in the figure ... with the
additional rule that tuplet figures beginning in a rest cause the
tuplet direction to equal down.
With the example above, probably the easiest thing to do is to force
tuplet bracket direction with
\override TupletBracket #'direction = #down
or
\override TupletBracket #'direction = #up
depending on preference. When you want Lily to resume dynamically
positioning the tuplet bracket direction, just write
\revert TupletBracket #'direction
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
NEWS source typo: \override NoteHead #'duration-log = 1
Hi, Just wanted to say thanks to whoever sponsored (or implemented) softcoded NoteHead #'duration-log. Specifying duration-log the old way was a lot more complicated (involving \tweak and angled and chord brackets, even for a single note). Minor point that the NEWS source for the feature reads \override NoteHead #'duration-log = 1 and should instead read \override NoteHead #'duration-log = #1 Thanks again. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Bus error on skip within doubly-nested tuplets
Hi,
A skip within a doubly-nested tuplet causes a bus error. For example ...
%%% BEGIN BUG %%%
\version 2.9.26
\new Staff {
\times 2/3 {
\times 2/3 {
c'8
s4 % THIS IS THE OFFENDING EXPRESSION
}
c'4
c'4
c'4
}
}
%%% END BUG %%%
... generates the following:
GNU LilyPond 2.9.26
Processing `0016.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects... Bus error
The skip is required for the error; changing the note to a skip like
this interprets fine:
%%% BEGIN OK %%%
\version 2.9.26
\new Staff {
\times 2/3 {
\times 2/3 {
c'8
c'4 % THIS IS OK
}
c'4
c'4
c'4
}
}
%%% END OK %%%
The error seems somewhat important, given that interpretation stops completely.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: More font drama when using EPS backend (OS X)
On further tinkering, the problem I'm describing below goes away when
I specify both a backend with -b or --backend AND also an output
format with -f or --formats.
For example,
lilypond --backend=eps foo.ly
explodes, but
lilypond --backend=eps --formats=ps foo.ly
works just fine. (All under 2.9.16 again.)
Makes sense, I guess. Just didn't think that I had to pair the
commandline parameters.
So I guess this isn't a bug and shouldn't go on the buglist. The eps
backend works fine under OS X Intel (also PPC) so long as there's a
corresponding specification for output format.
On 8/28/06, Trevor Bača [EMAIL PROTECTED] wrote:
Hi,
With 2.9.16 under OS X Intel, the following causes ghostscript to fail.
(Daniel Tonda noticed the problem (or a similar problem) with
lilypond-book under Windows and Mats moved the discussion to
bug-lilypond here on 8 August, with Daniel saying that the bug shows
up at about version 2.9.11.
http://lists.gnu.org/archive/html/bug-lilypond/2006-08/msg00051.html
If I'm seeing the same problem, then the bug exists under OS X, too.)
(Also, I mentioned this bit in the recent EPS thread ...
http://lists.gnu.org/archive/html/lilypond-user/2006-08/msg00340.html
... but I'm pretty sure this belongs on the bug list.)
Here's the sample file:
%%% BEGIN %%%
\version 2.9.16
\new Staff { c'4 }
%%% END %%%
And here's the output of
lilypond --verbose --backend=eps 302.ly
%%% OUTPUT %%%
trevor-bacas-computer:~/Documents/music/lilypond/test trevorbaca$
lilypond --verbose -b eps 302.lyGNU LilyPond 2.9.16
warning: Relocation: from
PATH=/sw/bin:/sw/sbin:/usr/local/bin:/Applications/LilyPond.app/Contents/Resources/bin/:/Applications/LilyPond.app/Contents/Resources/share/ghostscript/8.50/lib/:/bin:/sbin:/usr/bin:/usr/sbin
argv0=lilypond
warning: Relocation: compile prefix=/usr/share/lilypond/2.9.16, new
prefix=/Applications/LilyPond.app/Contents/Resources
PATH=/Applications/LilyPond.app/Contents/Resources/bin (prepend)
Setting PATH to
/Applications/LilyPond.app/Contents/Resources/bin:/sw/bin:/sw/sbin:/usr/local/bin:/Applications/LilyPond.app/Contents/Resources/bin/:/Applications/LilyPond.app/Contents/Resources/share/ghostscript/8.50/lib/:/bin:/sbin:/usr/bin:/usr/sbin
warning: Relocation:
framework_prefix=/Applications/LilyPond.app/Contents/Resources/bin/..
Setting INSTALLER_PREFIX to /Applications/LilyPond.app/Contents/Resources/bin/..
Relocation file
/Applications/LilyPond.app/Contents/Resources/bin/../etc/relocate//fontconfig.reloc
Setting FONTCONFIG_FILE to
/Applications/LilyPond.app/Contents/Resources/bin/../etc/fonts/fonts.conf
Setting FONTCONFIG_PATH to
/Applications/LilyPond.app/Contents/Resources/bin/../etc/fonts
Relocation file
/Applications/LilyPond.app/Contents/Resources/bin/../etc/relocate//gs.reloc
warning: no such directory:
/Applications/LilyPond.app/Contents/Resources/bin/../share/ghostscript/8.50/fonts
for GS_FONTPATH
warning: no such directory:
/Applications/LilyPond.app/Contents/Resources/bin/../share/gs/fonts
for GS_FONTPATH
warning: no such directory:
/Applications/LilyPond.app/Contents/Resources/bin/../share/ghostscript/8.50/Resource
for GS_LIB
GS_LIB=/Applications/LilyPond.app/Contents/Resources/bin/../share/ghostscript/8.50/lib
(prepend)
Setting GS_LIB to
/Applications/LilyPond.app/Contents/Resources/bin/../share/ghostscript/8.50/lib:/Applications/LilyPond.app/Contents/Resources/share/ghostscript/8.50/lib
Relocation file
/Applications/LilyPond.app/Contents/Resources/bin/../etc/relocate//guile.reloc
GUILE_LOAD_PATH=/Applications/LilyPond.app/Contents/Resources/bin/../share/guile/1.8
(prepend)
Setting GUILE_LOAD_PATH to
/Applications/LilyPond.app/Contents/Resources/bin/../share/guile/1.8
Relocation file
/Applications/LilyPond.app/Contents/Resources/bin/../etc/relocate//libtool.reloc
DYLD_LIBRARY_PATH=/Applications/LilyPond.app/Contents/Resources/bin/../lib
(prepend)
Setting DYLD_LIBRARY_PATH to
/Applications/LilyPond.app/Contents/Resources/bin/../lib
Relocation file
/Applications/LilyPond.app/Contents/Resources/bin/../etc/relocate//pango.reloc
Setting PANGO_RC_FILE to
/Applications/LilyPond.app/Contents/Resources/bin/../etc/pango/pangorc
Setting PANGO_PREFIX to /Applications/LilyPond.app/Contents/Resources/bin/../
Setting PANGO_SO_EXTENSION to .so
PATH=/Applications/LilyPond.app/Contents/Resources/bin/../bin (prepend)
Setting PATH to
/Applications/LilyPond.app/Contents/Resources/bin/../bin:/Applications/LilyPond.app/Contents/Resources/bin:/sw/bin:/sw/sbin:/usr/local/bin:/Applications/LilyPond.app/Contents/Resources/bin/:/Applications/LilyPond.app/Contents/Resources/share/ghostscript/8.50/lib/:/bin:/sbin:/usr/bin:/usr/sbin
Setting GUILE_MIN_YIELD_1 to 70
Setting GUILE_MIN_YIELD_2 to 70
Setting GUILE_MIN_YIELD_MALLOC to 70
LILYPOND_DATADIR=/usr/share/lilypond/2.9.16
LOCALEDIR=/usr/share/locale
Effective prefix:
/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current
FONTCONFIG_FILE=/Applications/LilyPond.app/Contents/Resources/bin
More font drama when using EPS backend (OS X)
-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/script-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/scale-definitions-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/grace-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/midi-init.ly[/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/performer-init.ly]][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/paper-defaults.ly[/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/titling-init.ly]][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/engraver-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/dynamic-scripts-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/spanners-init.ly][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ly/property-init.ly]][302.ly] Interpreting music... [/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-20.otf] elapsed time: 0.03 seconds Element count 25 (spanners 7) Preprocessing graphical objects... Grob count 47[/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-11.otf][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-13.otf][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-14.otf][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-16.otf][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-18.otf][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/fonts/otf/emmentaler-23.otf] Calculating line breaks... [2] Optimal demerits: 103.495995 Drawing systems... Element count 36.[0] Calculating page breaks...[century_schoolbook_l_3.865234375] Writing 302-systems.tex... Writing 302-systems.texi... Layout output to `302-1.eps'...[/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ps/music-drawing-routines.ps][/Applications/LilyPond.app/Contents/Resources/bin/../share/lilypond/current/ps/lilyponddefs.ps] Converting to `302-1.pdf'... Invoking `gs -dSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=302-1.pdf -c .setpdfwrite -f 302-1.eps'...GPL Ghostscript 8.50 (2005-12-31) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. WARNING: /Unicode /Decoding resource is not accessible but it is useful for generating ToUnicode CMap. Can't find (or can't open) font file c059013l.pfb. Can't find (or can't open) font file /Applications/LilyPond.app/Contents/Resources/share/ghostscript/8.50/Resource/Font/CenturySchL-Roma. Can't find (or can't open) font file CenturySchL-Roma. Querying operating system for font files... Didn't find this font on the system! Substituting font NewCenturySchlbk-Roman for CenturySchL-Roma. Unable to substitute for font. Error: /invalidfont in findfont Operand stack: CenturySchL-Roma 2.19953 CenturySchL-Roma Font CenturySchL-Roma 407279 CenturySchL-Roma --nostringval-- CenturySchL-Roma NewCenturySchlbk-Roman Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 2 3 %oparray_pop --nostringval-- 3 3 %oparray_pop 4 3 %oparray_pop --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 7 4 %oparray_pop --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- --nostringval-- 1 -1 1 --nostringval-- %for_neg_int_continue Dictionary stack: --dict:1122/1686(ro)(G)-- --dict:0/20(G)-- --dict:107/200(L)-- --dict:17/17(ro)(G)-- --dict:1122/1686(ro)(G)-- Current allocation mode is local Last OS error: 2 Current file position is 5895 GPL Ghostscript 8.50: Unrecoverable error, exit code 1 `gs -dSAFER -dEPSCrop -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=302-1.pdf -c .setpdfwrite -f 302-1.eps' failed (256) error: failed files: 302.ly %%% END OUTPUT %%% BTW, is anyone else able to use --backend=eps under OS X with 2.9.16?? -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond
Re: fraction-tuplet-formatter
On 8/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello since the version 2.9.12 i am having this error : Unbound variable : fraction-tuplet-formatter since i use it in conetxt as tupletNumberFormatFunction = #fraction-tuplet-formatter i am using the latest dev release 2.9.14-1 om Macosx ppc I beleive it is related to Trevor's changes. Hey Karim, Yeah, I worked with Han-Wen on 2.9.12 to make it possible to format nested tuplets independently -- you can, for example, now use fraction formatting on an outer tuplet and use single-digit formatting on the inner tuplets. Han-Wen's implementation works great and tupletNumberFormatFunction is now deprecated. Try running convert-ly on your input file, making sure that \version 2.9.12 appears at the top of your file. Then examine the output of convert-ly to see the new structures that are available. *(By the way i have visited your site Trevor, great stuff! tell me when u finish your piece.) Yeah, thanks! That piece actually finished a week ago before I left for Darmstadt. And it was a big hit with its dedicatee, the mind-blowingly good flutist Carin Levine. I'll share with the whole list sometime later this week because lily was a *huge* factor in my getting that piece done ... (Oh, and if anyone's flying to the UK or US in the next couple of days, for the love of god don't try to carry any shampoo through security.) -- Trevor Bača [EMAIL PROTECTED] ... like the dew, or like lightning ... ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
removing Stem_engraver blows up polyphony
Hi,
This snippet with the Stem_engraver removed works fine.
%%% OK %%%
\version 2.9.13
\new Staff {
\new Voice \with {
\remove Stem_engraver
} {
b'4
f'4
g'4
c''4
}
}
%%% END OK %%%
But this polyphonic snippet (also with the Stem_engraver removed) blows up.
%%% BUG %%%
\version 2.9.13
\new Staff {
\new Voice {
c'''4
c'''4
c'''4
c'''4
}
\new Voice \with {
\remove Stem_engraver
} {
b'4
f'4
g'4
c''4
}
}
%%% END BUG %%%
Here's the output.
Wed Jul 26 23:19:28 CDT 2006
convert-ly (GNU LilyPond) 2.9.13
Processing `264.ly'...
Applying conversion:
GNU LilyPond 2.9.13
Processing `264.ly'
Parsing...
Interpreting music... [1]
Preprocessing graphical objects... Error: /undefinedfilename in (264.ps)
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval--
--nostringval-- 2 %stopped_push --nostringval--
--nostringval-- --nostringval-- false 1 %stopped_push
Dictionary stack:
--dict:1122/1686(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.50: Unrecoverable error, exit code 1
FWIW, this is *not* an urgent bug for me since I'm comfortable setting
Stem #'transparent = ##t to achieve pretty much the same thing.
--
Trevor Bača
[EMAIL PROTECTED]
... like the dew, or like lightning ...
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Landscape papers broken in 2.9.11
On 7/16/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
I suspect the recent patch by Guido Amoruso for setting papersizes. Is
the PS output also faulty?
IIRC, it only affected the PDF generation.
OK, yes this is right; the postscript is fine, the conversion to pdf
is the problem.
So some fiddling produces the following workaround:
1. make sure ps2pdf is in the PATH
2. set GS_LIB before calling ps2pdf
3. call ps2pdf on the source postscript file with PAPERSIZE set manually
The OS X step-by-step is then
export PATH=/Applications/LilyPond.app/Contents/Resources/bin:$PATH
export
GS_LIB=/Applications/LilyPond.app/Contents/Resources/share/ghostscript/8.50/lib/
ps2pdf -sPAPERSIZE=11x17 foo.ps
Adjust /whatever/LilyPond.app accordingly for other OSes.
2006/7/15, Trevor Bača [EMAIL PROTECTED]:
Hi,
The 'landscape symbol supplied to set-default-paper-size appears to no
longer work under 2.9.11. (Worked fine under 2.9.10.)
%%% BEGIN BUG SNIPPET %%%
\version 2.9.11
#(set-default-paper-size a4 'landscape)
\new Staff {
c'4
}
%%% END SNIPPET %%%
This one's fairly critical for me; is there a way to work around this?
Possibly by setting something special for ghostscript? Or wasn't there
work done on the papesize files recently ... possibly I can edit one
of the .scm files for paper sizing and restore the landscape
orientation?
--
Han-Wen Nienhuys
[EMAIL PROTECTED]
http://www.xs4all.nl/~hanwen
--
Trevor Bača
[EMAIL PROTECTED]
like the dew or like lightning
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Landscape papers broken in 2.9.11
Hi,
The 'landscape symbol supplied to set-default-paper-size appears to no
longer work under 2.9.11. (Worked fine under 2.9.10.)
%%% BEGIN BUG SNIPPET %%%
\version 2.9.11
#(set-default-paper-size a4 'landscape)
\new Staff {
c'4
}
%%% END SNIPPET %%%
This one's fairly critical for me; is there a way to work around this?
Possibly by setting something special for ghostscript? Or wasn't there
work done on the papesize files recently ... possibly I can edit one
of the .scm files for paper sizing and restore the landscape
orientation?
--
Trevor Bača
[EMAIL PROTECTED]
like the dew or like lightning
251.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: tuplet brackets colliding or missing
On 5/12/06, karim haddad [EMAIL PROTECTED] wrote: hi I don't know if it is a bug feature or the problem of overriding many things ? But i encounter theses features using the very good and practical multiple tuplets by Trevor : 1- sometimes (and i don;t seem to know why ?) brackets are overlapping c.f mesure 2, 5 and 9 Hi Karim, Maybe tweaking the 'staff-padding and 'padding settings for TupletBracket can help? Like this: %%% these two overrides work together %%% \override TupletBracket #'staff-padding = #1.5 \override TupletBracket #'padding = #2 This combination cleans up all the overlaps except the 3:2 in measures 5 and 9; see answer to next question. 2- sometimes like above , brackets simply are not displayed like here in this example , mesure 5 the first 3/2 tuplet. These brackets aren't showing up because Lily decides there's no room to display them. The solution is to create more room. Probably the easiest way to create more room is to insert manual \break commands. I've put just two \break commands in your input; the 3:2 brackets now have room to print. See attached. i tried a3 paper, and landscape with nearly same results. standard noteheads, etc i am joining the code and pict THanx again. (will soon feedback on my musical work typeseted by super lily...) Unrelated question: are you using the diamond noteheads because you like the diamonds, or because you want the stems to align at the exact *center* of the notehead (like in Xenakis)? -- Trevor Bača [EMAIL PROTECTED] karim.png Description: PNG image debug.ly Description: Binary data ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: nested tuplets
On 4/5/06, karim haddad [EMAIL PROTECTED] wrote: Hello First of all , i wish to say thanx to everybody working on the dev of lily. the last version is great. Ok, now for some remarks. the nested tuplets feature which is really great has however one inconvenient. As we can see in the news doc, when these occur the brackets are too tight i.e they are too close one on the other and sometimes very hard to read. Is there a way to add some extra space between them. This would be great. Hi Karim, Two good things help with tuplet bracket positioning: 1. You can use \override TupletBracket #'staff-padding = #5.0 % or whatever value you like ... to move the whole nest of brackets up to so some uniform level above the staff; this will set all the *innermost* brackets level with each other, meaning that toplevel brackets will just stack higher and higher. 2. You can use \override TupletBracket #'padding = #2.3 % or whatever value you want ... to adjust the exact spacing that you're talking about *between* the brackets in the nest. I find values between #1.5 and #3.0 work nicely. Remember, too, if you're doing a lot of things with nested prolation that you can control the graphic object properties of the tuplet number with the TupletNumber grob (which is now independent of the TupletBracket grob). And you can force the tuplet number as a fraction with \set tupletNumberFormatFunction = #fraction-tuplet-formatter. Hope this helps; the total set of time-notation features in lily now is amazing. I can't think of a better vehicle for sketching rhythmic material for a piece. If you find something you *can't* set, please say something. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.7.38 bug: proportional duration beaming of 32nds and greater
On 3/16/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Trevor Bača wrote: Ugh. The exact conditions to induce this bug are very difficult. It is possible to come up with an example with somewhat fewer notes and fewer measures, like this: ... but cutting the example down even further usually causes the problem to no longer manifest. Thanks, this was a particularly hairy bug, but it's fixed now. The problem is that we reorder long grob lists when they cross line-breaks. This is good for efficiency, and harmless for unordered sets of grobs. Of course, stems of a beam are ordered, and it shouldn't happen there. Really appreciate the work on this particular bug; I couldn't even get my bug files to test consistently, much less get a reasonable intuition for which parts of the code might be effected. Thanks, Han-Wen. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.7.38 bug: proportional duration beaming of 32nds and greater
On 3/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Trevor Bača wrote: This is a weird one. If you have the following three conditions ... yes, it's a build issue. Only MacOS has this problem. Ah, yes. Sorry I didn't mention: I am, in fact, on OS X. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.7.38 bug: proportional duration beaming of 32nds and greater
On 3/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Trevor Bača wrote: On 3/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Trevor Bača wrote: This is a weird one. If you have the following three conditions ... yes, it's a build issue. Only MacOS has this problem. Ah, yes. Sorry I didn't mention: I am, in fact, on OS X. can you see if you can further reduce it? ie. less notes, less measures, etc. Only shows up if the combination of the number of notes together with the make-moment value to proportionalNotationDuration causes the beamed part of the expression to break across lines. So I'm having a hard time stretching the example out with ever smaller values to proportionalNotationDuration (meaning that I'm having a hard time reducing the overall number of notes in the example). I'll try more during lunch here next hour. -- Trevor Bača [EMAIL PROTECTED] ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: 2.7.38 bug: proportional duration beaming of 32nds and greater
On 3/15/06, Trevor Bača [EMAIL PROTECTED] wrote:
On 3/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Trevor Bača wrote:
On 3/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote:
Trevor Bača wrote:
This is a weird one. If you have the following three conditions ...
yes, it's a build issue. Only MacOS has this problem.
Ah, yes. Sorry I didn't mention: I am, in fact, on OS X.
can you see if you can further reduce it? ie. less notes, less
measures, etc.
Only shows up if the combination of the number of notes together with
the make-moment value to proportionalNotationDuration causes the
beamed part of the expression to break across lines. So I'm having a
hard time stretching the example out with ever smaller values to
proportionalNotationDuration (meaning that I'm having a hard time
reducing the overall number of notes in the example).
I'll try more during lunch here next hour.
Ugh. The exact conditions to induce this bug are very difficult.
It is possible to come up with an example with somewhat fewer notes
and fewer measures, like this:
BEGIN
\version 2.7.38
\new Score \with {
proportionalNotationDuration = #(ly:make-moment 1 256)
}
\new Staff {
\set allowBeamBreak = ##t
\time 2/8
c'8[
c'32 c'32 c'32 c'32
c'8
c'32 c'32 c'32 c'32
c'8
c'32 c'32 c'32 c'32]
}
%%% END %
... but cutting the example down even further usually causes the
problem to no longer manifest.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
2.7.38 TupletBracket line-breaking bug with tupletFullLength
With tupletFullLength = ##t, TupletBracket line-breaking logic falsely
duplicates TupletNumber at beginning-of-line. In the snippet below, an
errant 3 appears at the beginning of line 2.
%% BEGIN tupletFullLength BUG %%
\version 2.7.38
\new Staff {
\set tupletFullLength = ##t
\time 1/4
\times 2/3 {
c'8 c'8 c'8
}
\bar | \break
c'4
}
%%% END %
Bug is not release critical because tupletFullLength does not appear
in 2.6 and is new to 2.7.
--
Trevor Bača
[EMAIL PROTECTED]
tupletFullLength.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
2.7.38 bug: proportional duration beaming of 32nds and greater
This is a weird one. If you have the following three conditions ...
1. proportionalNotationDuration turned on
2. allowBeamBreak turned on
3. long, manually beamed figure involving 32nds, 64ths, 128ths (3 or
more beams)
... then secondary, tertiary, n-ary, beams continue beyond their span.
It is quite reproducible, but you need the argument to make-moment in
proportionalNotationDuration to be sufficiently small as to cause your
music to stretch across multiple lines; maybe the line-breaking logic
is a place to check.
Minimal example:
%%% BEGIN PROPORTIONAL BEAMING BUG %%%
\version 2.7.38
\new Score \with {
proportionalNotationDuration = #(ly:make-moment 1 64)
}
\new Staff {
\set allowBeamBreak = ##t
\time 1/8
c'8[
c'32 c'32 c'32 c'32
c'8
c'32 c'32 c'32 c'32
c'8
c'32 c'32 c'32 c'32
c'8
c'32 c'32 c'32 c'32
c'8]
}
END %%
Bug is not release critical because proportional notation was not
available in 2.6 and is new to 2.7.
--
Trevor Bača
[EMAIL PROTECTED]
proportional-beaming.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: uniform-stretching messes up note-spacing around time-signature changes
On 3/13/06, Marcus Macauley [EMAIL PROTECTED] wrote:
When following Trevor's suggestion, to use
\override SpacingSpanner #'uniform-stretching = ##t
if I wanted my tuplets spaced evenly, I discovered one and then two spacing
bugs
which occur only when uniform-stretching is on, and which appear to affect all
notes (not just tuplets) near a change of time signature, whether it occurs in
the middle of a line (which causes one problem) or at the end of a line (which
causes a different problem).
The following Lilypond file contains a description and several examples of
each
problem.
Marcus
% Bug: The command, \override SpacingSpanner #'uniform-stretching = ##t
% , causes at least two distinct problems with spacing of notes (tuplets or
% straight notes) around time-signature changes.
%First, needless extra space is created after a mid-line time-signature
% change. (measures 4, 6, 8, 10, 12, 13)
%Second, needed space is taken away from the end of the measure
immediately
% before an end-of-line time-signature change. (measures 15, 17, 19)
%Both of these problems seeem to occur regardless of whether tuplets are
% involved in any way.
%When the \override line is commented out, the spacing is correct.
\version 2.7.38
\score {
\new Score \with {
% Comment out the next line to see the tuplets spaced correctly.
\override SpacingSpanner #'uniform-stretching = ##t
}
\relative c'' { \time 2/4
\times 2/3 {c4 c c} \times 2/3 {c4 c c} \break % 1|2|
\times 2/3 {c4 c c} \time 2/4 \times 2/3 {c4 c c} \break % 3|4|
c8 c c c \time 2/4 \times 2/3 {c4 c c} \break % 5|6|
\times 2/3 {c4 c c} \time 2/4 c8 c c c \break % 7|8|
c8 c c c \time 2/4 c8 c c c \break % 9|10|
c8 c c c \time 1/4 c8 c \time 2/4 c8 c c c \break % 11|12|13|
\times 2/3 {c4 c c} \times 2/3 {c4 c c} \break \time 2/4 % 14|15|
c8 c c c \times 4/5 {c8 c c c c}\break \time 3/4 % 16|17|
\times 3/4 {c4 c c c} c4 c c \break \time 2/4 % 18|19|
}
\layout {
indent = #0
line-width = #75
}
}
Hi Marcus,
Yeah, unfortunately I don't have an answer for this one and you're
examples look like a valid report.
I know Erik likes to keep bug examples as small as possible, so maybe
we could extract two particularly good bits from the example above?
Measure 1 through 4 demonstrate the beginning-of-measure gap quite clearly:
% uniform-stretching SPACING BUG 1 %
% Marcus Macauley
\version 2.7.38
\new Score \with {
\override SpacingSpanner #'uniform-stretching = ##t
}
\relative c'' {
\time 2/4
\times 2/3 {c4 c c}
\times 2/3 {c4 c c} \break
\times 2/3 {c4 c c}
\time 2/4 \times 2/3 {c4 c c} % BEG-OF-MEASURE BUG: gap after time signature
}
\layout {
indent = #0
line-width = #75
}
% END 1 %%
And measures 16 17 show the end-of-measure problem particularly well
since there's an actual collision:
% uniform-stretching SPACING BUG 2 %
% Marcus Macauley
\version 2.7.38
\new Score \with {
\override SpacingSpanner #'uniform-stretching = ##t
}
\relative c'' {
\time 2/4
c8 c c c
\times 4/5 {c8 c c c c} \break % END-OF-MEASURE BUG: collision
\time 3/4
}
\layout {
indent = #0
line-width = #75
}
% END 2 %%
Then again, Erik might be perfectly happy with the original example, too.
Either way the pair of bugs probably aren't release critical since
uniform-stretching became available only recently in 2.7. (But
hopefully will get some attention once the 2.9 development cycle
begins.)
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Exotic color constants fail to parse
Hi,
This snippet ...
BEGIN SNIPPET %%%
\version 2.7.35
\new Staff {
\once \override NoteHead #'color = #azure
c'4
}
END SNIPPET
... fails to parse under OS X with .35 and instead issues
Parsing...ERROR: Unbound variable: azure
Same holds for salmon, chocolate and the other color constants I've
tried listed under appendix C (with the exception of the 15 normal
colors, all of which work great.)
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Exotic color constants fail to parse
On 3/4/06, Trevor Bača [EMAIL PROTECTED] wrote:
Hi,
This snippet ...
BEGIN SNIPPET %%%
\version 2.7.35
\new Staff {
\once \override NoteHead #'color = #azure
c'4
}
END SNIPPET
... fails to parse under OS X with .35 and instead issues
Parsing...ERROR: Unbound variable: azure
Same holds for salmon, chocolate and the other color constants I've
tried listed under appendix C (with the exception of the 15 normal
colors, all of which work great.)
PLEASE DISREGARD report given above.
There is no such bug; my calling syntax was incorrect. Section 8.5.7
Coloring objects, corrects my problem as follows:
%%% BEGIN FIXED SNIPPET %
\version 2.7.35
\new Staff {
\once \override NoteHead #'color = #(x11-color 'azure)
c'4
}
END SNIPPET %%%
User error; not a bug.
--
Trevor Bača
[EMAIL PROTECTED]
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Two smarter tuplet defaults concerning fraction-tuplet-formatter
Hi folks,
2.7.35 looks great so far. I haven't found any additional
release-critical bugs that haven't already been reported and fixed.
So I thought I'd introduce two engraving standards that Lily doesn't
yet implement, but maybe should for 2.8. Both defaults should be very
straightforward to change (I think) and both cause actual engraving
errors. The conventions concern when to use #fraction-tuplet-formatter
as tupletNumberFormatFunction.
TUPLET CONVENTION 1. Consider the following:
%%% EXAMPLE 1A - notation impossible to rhythmically disambiguate %%%
\new Score
\new RhythmicStaff {
\time 7/8
\times 5/3 {c'8 c'8 c'8}
\times 2/3 {c'8 c'8 c'8}
}
%%% END %
Make sure to actually take a look at the resulting notation, because
the input is harmless.
Lily renders both triplets by default with a lone tuplet number 3.
This is an engraving error, but one that we're only likely recognize
if we work with a lot of tuplet. The primary convention for
interpreting tuplets (and the only one with which a larger number of
players are familiar) is something like a lone number p is
interpreted as the ratio p:q where q is *the next integer power of 2
just less that p*. This is what causes us to interpret a lone 3 as
3:2 instead of, say, 3:4 or 3:5.
That convention -- the how to read a lone tuplet number convention
-- works fine for the second triplet in 1a, but fails completely for
the first triplet.
Why?
Because of that first convention (which covers tuplet denominators
that are integer powers of 2), there's an implicit second convention
that says whenever you've got a tuplet ratio in the for p:q where q
is *NOT* an integer power of 2, make sure you print p:q as an explicit
fraction, (unless explicitly overriden the user).
Here's the fix:
% EXAMPLE 1b - correct %%
\new Score
\new RhythmicStaff {
\time 7/8
\once \set tupletNumberFormatFunction = #fraction-tuplet-formatter
\times 5/3 {c'8 c'8 c'8}
\times 2/3 {c'8 c'8 c'8}
}
% END
So, very easy solution:
SMART TUPLET DEFAULT 1: by default, Lily should render tuplets of the
form p:q (with q *NOT* an integer power of 2) using
tupletNumberFormatFunction set equal to #fraction-tuplet-formatter.
Next up:
TUPLET CONVENTION 2. Consider the following different, but related, snippet:
%%% EXAMPLE 2A - notation impossible to rhythmically disambiguate
\new Score
\new RhythmicStaff {
\time 6/8
\times 4/3 {c'8[ c'8 c'8]}
\times 2/3 {c'8[ c'8 c'8]}
}
%%% END %%
Once again, make sure to look at the actual resulting notation.
Here again it's impossible to tell the rhythm of any single note in
the measure, but this time for a different reason.
Here, the tuplet ratios are 3:4 and 3:2 which, happily, both have
tuplet denominators that are integer powers of 2 (ie, 2 and 4) ...
which is what makes this example different than the 3:5 in examples
1a and 1b.
So what's breaking? Well, there's another convention on the engraving
of tuplets that says something like if you've got a tuplet ratio p:q
where p q then make sure to engraver p:q as an explicit fraction
*even if q is an integer power of 2*. The reason is clear enough: the
usual interpretation for a missing q reads q as the first integer
power of 2 just *less* than p ... which is the opposite of our 3:4
example where 4 is in the integer power of 2 just *more* than p.
The fix is once again to set tupletNumberFormatFunction to
#fraction-tuplet-formatter:
EXAMPLE 2B - correct
\new Score
\new RhythmicStaff {
\time 6/8
\once \set tupletNumberFormatFunction = #fraction-tuplet-formatter
\times 4/3 {c'8[ c'8 c'8]}
\times 2/3 {c'8[ c'8 c'8]}
}
END %%
So another simple default:
SMART TUPLET DEFAULT 2: by default, Lily should render tuplets of the
for p:q (with p q) using tupletNumberFormatFunction set equal to
#fraction-tuplet-formatter.
Anyway, that was a lot of writing to say Lily should use
#fraction-tuplet-formatter when either q is *not* an integer power of
2 or when p q, for any tuplet p:q. Maybe even more concise to say
if you've got a tuplet ratio where q is *anything other than* the
integer power of 2 just *less* than p, you need to explicitly print
p:q with #fraction-tuplet-formatter.
Probably low priority since the workaround of setting
#fraction-tuplet-formatter is clear to folks who work with a lot of
tuplets. Nonetheless, hope this helps.
--
Trevor Bača
[EMAIL PROTECTED]
1a.png
Description: PNG image
1b.png
Description: PNG image
2a.png
Description: PNG image
2b.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Two smarter tuplet defaults concerning fraction-tuplet-formatter
Hi folks,
2.7.35 looks great so far. I haven't found any additional
release-critical bugs that haven't already been reported and fixed.
So I thought I'd introduce two engraving standards that Lily doesn't
yet implement, but maybe should for 2.8. Both defaults should be very
straightforward to change (I think) and both cause actual engraving
errors. The conventions concern when to use #fraction-tuplet-formatter
as tupletNumberFormatFunction.
TUPLET CONVENTION 1. Consider the following:
%%% EXAMPLE 1A - notation impossible to rhythmically disambiguate %%%
\new Score
\new RhythmicStaff {
\time 7/8
\times 5/3 {c'8 c'8 c'8}
\times 2/3 {c'8 c'8 c'8}
}
%%% END %
Make sure to actually take a look at the resulting notation, because
the input is harmless.
Lily renders both triplets by default with a lone tuplet number 3.
This is an engraving error, but one that we're only likely recognize
if we work with a lot of tuplet. The primary convention for
interpreting tuplets (and the only one with which a larger number of
players are familiar) is something like a lone number p is
interpreted as the ratio p:q where q is *the next integer power of 2
just less that p*. This is what causes us to interpret a lone 3 as
3:2 instead of, say, 3:4 or 3:5.
That convention -- the how to read a lone tuplet number convention
-- works fine for the second triplet in 1a, but fails completely for
the first triplet.
Why?
Because of that first convention (which covers tuplet denominators
that are integer powers of 2), there's an implicit second convention
that says whenever you've got a tuplet ratio in the for p:q where q
is *NOT* an integer power of 2, make sure you print p:q as an explicit
fraction, (unless explicitly overriden the user).
Here's the fix:
% EXAMPLE 1b - correct %%
\new Score
\new RhythmicStaff {
\time 7/8
\once \set tupletNumberFormatFunction = #fraction-tuplet-formatter
\times 5/3 {c'8 c'8 c'8}
\times 2/3 {c'8 c'8 c'8}
}
% END
So, very easy solution:
SMART TUPLET DEFAULT 1: by default, Lily should render tuplets of the
form p:q (with q *NOT* an integer power of 2) using
tupletNumberFormatFunction set equal to #fraction-tuplet-formatter.
Next up:
TUPLET CONVENTION 2. Consider the following different, but related, snippet:
%%% EXAMPLE 2A - notation impossible to rhythmically disambiguate
\new Score
\new RhythmicStaff {
\time 6/8
\times 4/3 {c'8[ c'8 c'8]}
\times 2/3 {c'8[ c'8 c'8]}
}
%%% END %%
Once again, make sure to look at the actual resulting notation.
Here again it's impossible to tell the rhythm of any single note in
the measure, but this time for a different reason.
Here, the tuplet ratios are 3:4 and 3:2 which, happily, both have
tuplet denominators that are integer powers of 2 (ie, 2 and 4) ...
which is what makes this example different than the 3:5 in examples
1a and 1b.
So what's breaking? Well, there's another convention on the engraving
of tuplets that says something like if you've got a tuplet ratio p:q
where p q then make sure to engraver p:q as an explicit fraction
*even if q is an integer power of 2*. The reason is clear enough: the
usual interpretation for a missing q reads q as the first integer
power of 2 just *less* than p ... which is the opposite of our 3:4
example where 4 is in the integer power of 2 just *more* than p.
The fix is once again to set tupletNumberFormatFunction to
#fraction-tuplet-formatter:
EXAMPLE 2B - correct
\new Score
\new RhythmicStaff {
\time 6/8
\once \set tupletNumberFormatFunction = #fraction-tuplet-formatter
\times 4/3 {c'8[ c'8 c'8]}
\times 2/3 {c'8[ c'8 c'8]}
}
END %%
So another simple default:
SMART TUPLET DEFAULT 2: by default, Lily should render tuplets of the
for p:q (with p q) using tupletNumberFormatFunction set equal to
#fraction-tuplet-formatter.
Anyway, that was a lot of writing to say Lily should use
#fraction-tuplet-formatter when either q is *not* an integer power of
2 or when p q, for any tuplet p:q. Maybe even more concise to say
if you've got a tuplet ratio where q is *anything other than* the
integer power of 2 just *less* than p, you need to explicitly print
p:q with #fraction-tuplet-formatter.
Probably low priority since the workaround of setting
#fraction-tuplet-formatter is clear to folks who work with a lot of
tuplets. Nonetheless, hope this helps.
--
Trevor Bača
[EMAIL PROTECTED]
1a.png
Description: PNG image
1b.png
Description: PNG image
2a.png
Description: PNG image
2b.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Cyan -- Yellow
The lowest-priority bug in the history of the project ...
%%% BEGIN SNIPPET
% the values of #yellow and #cyan are reversed
\version 2.7.29
\new Staff {
c'4
\once \override NoteHead #'color = #yellow
c'4^\yellow\
c'4
}
%%% END SNIPPET %
(color.ly shows the corresponding reversal where the cyan beam
renders as yellow.)
--
Trevor Bača
[EMAIL PROTECTED]
yellow.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
