Re: Issue 2358 in lilypond: Patch: Allow music with layout instructions in output definitions.
Updates: Status: Verified Comment #15 on issue 2358 by elu...@gmail.com: Patch: Allow music with layout instructions in output definitions. http://code.google.com/p/lilypond/issues/detail?id=2358 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2306 in lilypond: add info about Articulations on EventChords to CG
Comment #7 on issue 2306 by janek.li...@gmail.com: add info about Articulations on EventChords to CG http://code.google.com/p/lilypond/issues/detail?id=2306 It is in CG 10.16, LilyPond Miscellany. I see it online. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2357 in lilypond: Patch: web: rephrase bugreports section
Updates: Status: Verified Comment #5 on issue 2357 by elu...@gmail.com: Patch: web: rephrase bugreports section http://code.google.com/p/lilypond/issues/detail?id=2357 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2364 in lilypond: Patch: Don't use Bottom overrides (default when unspecified) in \tabFullNotation
Updates: Status: Verified Comment #6 on issue 2364 by elu...@gmail.com: Patch: Don't use Bottom overrides (default when unspecified) in \tabFullNotation http://code.google.com/p/lilypond/issues/detail?id=2364 verified to be in property-init.ly - how else could/should I test/verify?! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Verifying Issue 2338 OS X Lilypad not working Fwd: LilyPond 2.15.32 released
Hello,
On 6 March 2012 02:36, James Worlton wrote:
>
> On Mar 5, 2012, at 4:41 PM, Colin Hall wrote:
>
>>
>> Hi All,
>>
>> Thanks once again to all of you for volunteering to help the bug squad
>> verify new Lilypond releases on MacOS X.
>>
>> We have a new release which includes a candidate fix for Issue 2338,
>> the only remaining critical issue prior to the 2.16.0 release.
>>
>> http://code.google.com/p/lilypond/issues/detail?id=2338
>>
>> Please download 2.15.32 for your platform and check that it launches
>> ok. If you have a lilypond file you can run through it, even better.
>
>
> OSX 10.4.11 on PPC:
> Lily 2.15.32 app opens fine, and compiled a file with several includes. No
> problems for that part of it.
>
> However, my score had a construction similar to:
>
> \version "2.15.32"
> \score {
> \new Staff { a''4~ a''2.\fermata }
> }
>
> In this case, the fermata collides with the tie. Is that a known issue?
Yep.
http://code.google.com/p/lilypond/issues/detail?id=570
James
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Verifying Issue 2338 OS X Lilypad not working Fwd: LilyPond 2.15.32 released
On Mar 5, 2012, at 4:41 PM, Colin Hall wrote:
Hi All,
Thanks once again to all of you for volunteering to help the bug squad
verify new Lilypond releases on MacOS X.
We have a new release which includes a candidate fix for Issue 2338,
the only remaining critical issue prior to the 2.16.0 release.
http://code.google.com/p/lilypond/issues/detail?id=2338
Please download 2.15.32 for your platform and check that it launches
ok. If you have a lilypond file you can run through it, even better.
OSX 10.4.11 on PPC:
Lily 2.15.32 app opens fine, and compiled a file with several
includes. No
problems for that part of it.
However, my score had a construction similar to:
\version "2.15.32"
\score {
\new Staff { a''4~ a''2.\fermata }
}
In this case, the fermata collides with the tie. Is that a known issue?
James Worlton
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2349 in lilypond: Patch: Removes transparents in TabVoice and replaces with false stencil
Updates: Status: Verified Comment #12 on issue 2349 by colingh...@gmail.com: Patch: Removes transparents in TabVoice and replaces with false stencil http://code.google.com/p/lilypond/issues/detail?id=2349 Mike lists two committishes in Comment #10 but they are identical. Mikes gives 984b59eda4c1dded74567bc9eedcce2ba2ed0eb5 I think the other commit is 88a8754b318a85ae19ec0c566530b898f4331197 Verified that both commits are present in the repo. Also confirmed that they are part of 2.15.32 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2347 in lilypond: Patch: Improving \harmonicBy... functions
Updates: Status: Verified Comment #10 on issue 2347 by colingh...@gmail.com: Patch: Improving \harmonicBy... functions http://code.google.com/p/lilypond/issues/detail?id=2347 Verified that this patch is in the repo using Phil's web tool. Also confirmed committish is part of 2.15.32 using git log and grepping for the committish ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2320 in lilypond: Patch: CG: add information about Regtest Checking Project
Updates: Status: Verified Comment #16 on issue 2320 by colingh...@gmail.com: Patch: CG: add information about Regtest Checking Project http://code.google.com/p/lilypond/issues/detail?id=2320 Verified patch included in 2.15.32 by checking the commitish with git log origin. Also confirmed new documentation text present here: http://lilypond.org/doc/v2.15/Documentation/contributor/grand-regression-test-checking ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2306 in lilypond: add info about Articulations on EventChords to CG
Updates: Status: Verified Comment #6 on issue 2306 by colingh...@gmail.com: add info about Articulations on EventChords to CG http://code.google.com/p/lilypond/issues/detail?id=2306 Verified that patch is in the repo and contributed to the 2.15.32 release. I've marked this as verified. I'd like to have found the new documentation but I couldn't locate it. Should there be some new material under the Engraver Tutorial section? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \grace after \cadenzaOff suppresses auto-beams
Colin Hall writes:
> On Mon, Mar 05, 2012 at 07:11:12PM +0100, Jean-Charles Malahieude wrote:
>>
>> >And I just found a solution that works even better for me...
>> >
>> >%%% previous stuff
>> > \cadenzaOff
>> > \bar "|"
>> > \appoggiatura b4
>> > \set Timing.measurePosition = #(ly:make-moment 0 4)
>> >%%% subsequent stuff
>> >
>> >
>> >...by setting the measurePosition *after* the grace/appoggiatura and
>> >before the first "beat" of the measure, the beams remain intact and
>> >the warning disappears. Huzzah.
>>
>> But still "strange" if you consider the bar numbering (the same goes
>> with your accidentals' problem):
>>
>> \relative c' {
>> \override Score.BarNumber #'break-visibility = #'#(#t #t #t)
>> \set Score.currentBarNumber = #11
>> \bar ""
>> \time 2/4
>> c2
>> \cadenzaOn
>> c2 d8-[ e \bar "|" f g-]
>> \cadenzaOff
>> \bar "|"
>> \grace b8 \bar "|"
>> a4. \bar "|" gis8 \bar "|"
>> e'8 \bar "|" e \bar "|" e \bar "|" e
>> }
>
> David, Jean-Charles, can you help me decide what to do with this
> discussion thread?
>
> Have you isolated a bug here?
\cadenzaOff has "design artifacts" (various have been discussed here),
and \grace timing (our old friend) exacerbates the symptoms.
I don't think that it is worth filing a separate bug for the combination
with \grace. Some of the recent examples involving \cadenza... might be
worth filing an issue for redesign. It might be worth starting a
collection of them. Basically it works as expected giving the
implementation (and never did something else), but I actually have a
hard time imagining even a single case where it would actually do what
you'd want.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2380 in lilypond: formatting of lyrics
Updates: Status: Fixed Owner: d...@gnu.org Labels: -Type-Defect Type-Critical Regression Fixed_2_15_33 Comment #1 on issue 2380 by d...@gnu.org: formatting of lyrics http://code.google.com/p/lilypond/issues/detail?id=2380 Pushed a fix as 2bba3b65d5150ec62dda869bdb3a152b21a03504 to staging. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Verifying Issue 2338 OS X Lilypad not working Fwd: LilyPond 2.15.32 released
On Mon, Mar 05, 2012 at 05:57:21PM -0600, Stan Sanderson wrote: > ROn Mar 5, 2012, at 4:41 PM, Colin Hall wrote: > > > > > Hi All, > > > > Thanks once again to all of you for volunteering to help the bug squad > > verify new Lilypond releases on MacOS X. > > > > We have a new release which includes a candidate fix for Issue 2338, > > the only remaining critical issue prior to the 2.16.0 release. > > > > http://code.google.com/p/lilypond/issues/detail?id=2338 > > > > Please download 2.15.32 for your platform and check that it launches > > ok. If you have a lilypond file you can run through it, even better. > > > > This is to verify that 2.15.32 on OS X 10.5.8 PPC (G4) PowerBook > loaded and correctly processed an existing source file following > application of convert from Lilypad. Thanks, Stan, that's great. Good to hear that convert-ly worked too. > Sorry for the delay in reporting. Hardly! It was only released a few hours ago. Thanks again. Colin. -- Colin Hall ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \grace after \cadenzaOff suppresses auto-beams
On Mon, Mar 05, 2012 at 07:11:12PM +0100, Jean-Charles Malahieude wrote:
>
> >And I just found a solution that works even better for me...
> >
> >%%% previous stuff
> > \cadenzaOff
> > \bar "|"
> > \appoggiatura b4
> > \set Timing.measurePosition = #(ly:make-moment 0 4)
> >%%% subsequent stuff
> >
> >
> >...by setting the measurePosition *after* the grace/appoggiatura and
> >before the first "beat" of the measure, the beams remain intact and
> >the warning disappears. Huzzah.
>
> But still "strange" if you consider the bar numbering (the same goes
> with your accidentals' problem):
>
> \relative c' {
> \override Score.BarNumber #'break-visibility = #'#(#t #t #t)
> \set Score.currentBarNumber = #11
> \bar ""
> \time 2/4
> c2
> \cadenzaOn
> c2 d8-[ e \bar "|" f g-]
> \cadenzaOff
> \bar "|"
> \grace b8 \bar "|"
> a4. \bar "|" gis8 \bar "|"
> e'8 \bar "|" e \bar "|" e \bar "|" e
> }
David, Jean-Charles, can you help me decide what to do with this discussion
thread?
Have you isolated a bug here?
Cheers,
Colin.
--
Colin Hall
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
Neil Thornock writes: >>> Normal from what perspective? Where it left off before \cadenzaOn or >>> simply that it starts back at '0' immediately \cadenzaOff >>> >>> I'm wondering if we need something (a sentence of two) in the NR to >>> avoid what is obviously something that does confuse people. >> >> I still have not figured out the exact reasoning behind this. But it >> does not seem to be much more than "stop advancing time in measure" >> "start advancing time in measure again". If there is no material left >> to fill the bar, the measure will not get full. > > Actually, it resets timing to 0, so even if the bar has some notes > before \cadenzaOn, they don't get counted toward the timing once > \cadenzaOff is reached. So it is not "stop advancing time in measure > to resume later", but rather "stop counting altogether and then reset > to 0." > > I would think that once the timing is reset to 0, as \cadenzaOn does, > it should automatically insert a barline at that point and treat the > subsequent material as a new measure (thus avoiding problems with > accidentals). > > I really think this is a design flaw. The reason is that the settings engraver runs after timing and default bar engravers, so the opportunity for engraving a bar is already over when the timing is getting reset by \cadenzaOff. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Verifying Issue 2338 OS X Lilypad not working Fwd: LilyPond 2.15.32 released
ROn Mar 5, 2012, at 4:41 PM, Colin Hall wrote: > > Hi All, > > Thanks once again to all of you for volunteering to help the bug squad > verify new Lilypond releases on MacOS X. > > We have a new release which includes a candidate fix for Issue 2338, > the only remaining critical issue prior to the 2.16.0 release. > > http://code.google.com/p/lilypond/issues/detail?id=2338 > > Please download 2.15.32 for your platform and check that it launches > ok. If you have a lilypond file you can run through it, even better. > > Here's a table showing who has signed up for which platform. Stan has > already reported in for MacOS X 10.5.8 on x86. > > | MacOS X | x86/ppc | User | > | version | || > |-+-+| > | 10.4.x | ppc | Ole Schmidt| > | | | Valentin Villenave | > | | | James Worlton | > |-+-+| > | 10.4.11 | x86 | Klaus Foehl| > |-+-+| > | 10.4.x | x86 || > |-+-+| > | 10.5.8 | ppc | Stan Sanderson | > |-+-+| > | 10.5.8 | x86 | Stan Sanderson | Verified > |-+-+| > | 10.6.x | x86 || > |-+-+| > | 10.7.3 | x86 | Eric Schissel | > | | || > > > Looking forward to hearing from you. > > Best Regards, > Colin. > > - Forwarded message from Graham Percival - > > Date: Mon, 5 Mar 2012 16:56:18 + > From: Graham Percival > To: info-lilyp...@gnu.org > Subject: LilyPond 2.15.32 released > > We are happy to announce the release of LilyPond 2.15.32. This > release contains the usual number of bugfixes. > > It is strongly recommended that normal users do not use this > release, and instead use the stable 2.14 version. Please note that > due to a few Critical bugs, this is not the next release > candidate. > > - Graham > > ___ > Info-lilypond mailing list > info-lilyp...@gnu.org > https://lists.gnu.org/mailman/listinfo/info-lilypond > > - End forwarded message - > > -- > > Colin Hall This is to verify that 2.15.32 on OS X 10.5.8 PPC (G4) PowerBook loaded and correctly processed an existing source file following application of convert from Lilypad. Sorry for the delay in reporting. Stan ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Verifying Issue 2338 OS X Lilypad not working Fwd: LilyPond 2.15.32 released
Hi, Thanks for the responses so far, everyone. On Mon, Mar 05, 2012 at 10:41:53PM +, Colin Hall wrote: > We have a new release which includes a candidate fix for Issue 2338, > the only remaining critical issue prior to the 2.16.0 release. I thought that this bug was gating the 2.16.0 release but in fact there are several others to be dealt with first. Sorry for my inaccurate statement above! Anyway, still well worth getting this long standing bug verified as fixed, > http://code.google.com/p/lilypond/issues/detail?id=2338 > > Please download 2.15.32 for your platform and check that it launches > ok. If you have a lilypond file you can run through it, even better. > > Here's a table showing who has signed up for which platform. Ole has offerred to do MacOS X 10.6.8 x86 aswell, so the table now looks like this: | MacOS X | x86/ppc | User | | version | || |-+-+| | 10.4.x | ppc | Ole Schmidt| | | | Valentin Villenave | | | | James Worlton | |-+-+| | 10.4.11 | x86 | Klaus Foehl| |-+-+| | 10.5.8 | ppc | Stan Sanderson | |-+-+| | 10.5.8 | x86 | Stan Sanderson | |-+-+| | 10.6.8 | x86 | Ole Schmidt| |-+-+| | 10.7.3 | x86 | Eric Schissel | | | || When you report your results please let me know the full numeric ID for the release of MacOS X you are running e.g. 10.4.11 rather than just 10.4 Cheers, Colin. -- Colin Hall ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
On Mon, Mar 05, 2012 at 03:23:08PM -, Phil Holmes wrote:
>
> "David Bobroff" wrote in message
> news:4f547dc7.10...@centrum.is...
> >I'm re-framing my query regarding accidental behavior following
> >\cadenzaOff. After some discussion about this on bug- it is quite
> >clear that '\cadenzaOff' *only* affects counting/timing and '\bar'
> >*only* paints a graphic of a bar line. Currently, if an
> >accidental appears in the cadenza it will be visibly canceled if
> >the key signature value of the note is used in the next "measure"
> >even if '\cadenzaOff \bar "|."' is present. Musically this should
> >not happen. Since a bar line has gone by the key signature is
> >back in force.
> >
> >This post in on -user to see if anyone has a solution; how do I
> >suppress the accidental cancellation in the following example?
> >
> >I've posted this to bug- to suggest that LilyPond should probably
> >understand this.
> >
> >Example:
> >
> >%%%
> >\version "2.14.2"
> >
> >\relative c'
> >{
> > \key c \major
> > \time 2/4
> > c2 ~
> > \cadenzaOn
> > c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
> > \cadenzaOff
> > \bar "|"
> > e2 % how to suppress accidental cancellation here?
> >}
>
> Eluze added something about this as
> http://code.google.com/p/lilypond/issues/detail?id=2379
>
> Is that what was wanted?
I've added a comment to the tracker to link in this new thread.
Cheers,
Colin.
--
Colin Hall
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2379 in lilypond: resetting autoBeaming after a cadenza
Comment #1 on issue 2379 by colingh...@gmail.com: resetting autoBeaming
after a cadenza
http://code.google.com/p/lilypond/issues/detail?id=2379
David Bobroff restated the problem in a post here:
http://lists.gnu.org/archive/html/bug-lilypond/2012-03/msg00238.html
Text of original post follows:
I'm re-framing my query regarding accidental behavior following
\cadenzaOff. After some discussion about this on bug- it is quite clear
that '\cadenzaOff' *only* affects counting/timing and '\bar' *only* paints
a graphic of a bar line. Currently, if an accidental appears in the cadenza
it will be visibly canceled if the key signature value of the note is used
in the next "measure" even if '\cadenzaOff \bar "|."' is present. Musically
this should not happen. Since a bar line has gone by the key signature is
back in force.
This post in on -user to see if anyone has a solution; how do I suppress
the accidental cancellation in the following example?
I've posted this to bug- to suggest that LilyPond should probably
understand this.
Example:
%%%
\version "2.14.2"
\relative c'
{
\key c \major
\time 2/4
c2 ~
\cadenzaOn
c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
\cadenzaOff
\bar "|"
e2 % how to suppress accidental cancellation here?
}
%%%
-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Verifying Issue 2338 OS X Lilypad not working Fwd: LilyPond 2.15.32 released
Hi All, Thanks once again to all of you for volunteering to help the bug squad verify new Lilypond releases on MacOS X. We have a new release which includes a candidate fix for Issue 2338, the only remaining critical issue prior to the 2.16.0 release. http://code.google.com/p/lilypond/issues/detail?id=2338 Please download 2.15.32 for your platform and check that it launches ok. If you have a lilypond file you can run through it, even better. Here's a table showing who has signed up for which platform. Stan has already reported in for MacOS X 10.5.8 on x86. | MacOS X | x86/ppc | User | | version | || |-+-+| | 10.4.x | ppc | Ole Schmidt| | | | Valentin Villenave | | | | James Worlton | |-+-+| | 10.4.11 | x86 | Klaus Foehl| |-+-+| | 10.4.x | x86 || |-+-+| | 10.5.8 | ppc | Stan Sanderson | |-+-+| | 10.5.8 | x86 | Stan Sanderson | Verified |-+-+| | 10.6.x | x86 || |-+-+| | 10.7.3 | x86 | Eric Schissel | | | || Looking forward to hearing from you. Best Regards, Colin. - Forwarded message from Graham Percival - Date: Mon, 5 Mar 2012 16:56:18 + From: Graham Percival To: info-lilyp...@gnu.org Subject: LilyPond 2.15.32 released We are happy to announce the release of LilyPond 2.15.32. This release contains the usual number of bugfixes. It is strongly recommended that normal users do not use this release, and instead use the stable 2.14 version. Please note that due to a few Critical bugs, this is not the next release candidate. - Graham ___ Info-lilypond mailing list info-lilyp...@gnu.org https://lists.gnu.org/mailman/listinfo/info-lilypond - End forwarded message - -- Colin Hall ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2338 in lilypond: OS X LilyPad not working
Comment #43 on issue 2338 by colingh...@gmail.com: OS X LilyPad not working http://code.google.com/p/lilypond/issues/detail?id=2338 Phillipe reports 2.15.32 launches successfully on MacOS X 10.7 Lion x86 http://lists.gnu.org/archive/html/lilypond-user/2012-03/msg00125.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2338 in lilypond: OS X LilyPad not working
Comment #42 on issue 2338 by colingh...@gmail.com: OS X LilyPad not working http://code.google.com/p/lilypond/issues/detail?id=2338 Stan Sanderson reports that 2.15.32 launches on MacOS X 10.5.8 x86 http://lists.gnu.org/archive/html/lilypond-user/2012-03/msg00120.html ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2344 in lilypond: Kievan final barline gets cut off
Comment #10 on issue 2344 by aleksandr.andr...@gmail.com: Kievan final barline gets cut off http://code.google.com/p/lilypond/issues/detail?id=2344 I really think something along the lines of \stopStaff is the way to go. I'm trying to figure out how \stopStaff is coded up. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2344 in lilypond: Kievan final barline gets cut off
Comment #9 on issue 2344 by janek.li...@gmail.com: Kievan final barline gets cut off http://code.google.com/p/lilypond/issues/detail?id=2344 You could use extra-offset, but this doesn't work for the "snippet" thingy (it gets cut off again). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2378 in lilypond: Patch: Various updates to reduce make doc output
Updates: Labels: -Patch-countdown Patch-needs_work Comment #3 on issue 2378 by gra...@percival-music.ca: Patch: Various updates to reduce make doc output http://code.google.com/p/lilypond/issues/detail?id=2378 Julien and I have concerns about modifying the default behaviour of a few python scripts; we think they should be changed to take a --quiet option. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Formatting of lyrics
On Mon, Mar 5, 2012 at 6:30 AM, Francisco Vila wrote:
> 2012/3/5 -Eluze :
> > O.K. - see attachment - I am interested in the "R" at the end of even
> >> verses (symbol "R" I've created).
>
> gregorian.ly defines \ij \iij etc for prefixing and a two \responsum
> and \versus functions which do not seem to work. However, the unicode
> symbols used there still serve, see
>
> \include "gregorian.ly"
> { c' }
> \addlyrics { \set stanza = ℟ Do }
> \addlyrics { \set stanza = ℣ Do }
>
> Forwarding to bug-lilypond because this should workk but it doesn't:
>
> % %%% BEGIN
>
> \include "gregorian.ly"
> letraUno = \lyricmode { \versus { Do Do } }
> letraDos = \lyricmode { \responsum { Do Do } }
> { c' d' }
> \addlyrics \letraUno
> \addlyrics \letraDos
>
> % %%%END
Thank you for the report, Francisco and Eluze. I could not reproduce the
problem, because Lilypond crashes. I have submitted it as issue 2380 :
http://code.google.com/p/lilypond/issues/detail?id=2380
Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2380 in lilypond: formatting of lyrics
Status: Accepted
Owner:
Labels: Type-Defect
New issue 2380 by ralphbug...@gmail.com: formatting of lyrics
http://code.google.com/p/lilypond/issues/detail?id=2380
Franisco Vila writes:
gregorian.ly defines \ij \iij etc for prefixing and a two \responsum
and \versus functions which do not seem to work. However, the unicode
symbols used there still serve, see
\include "gregorian.ly"
{ c' }
\addlyrics { \set stanza = ℟ Do }
\addlyrics { \set stanza = ℣ Do }
Forwarding to bug-lilypond because this should workk but it doesn't:
% %%% BEGIN
\include "gregorian.ly"
letraUno = \lyricmode { \versus { Do Do } }
letraDos = \lyricmode { \responsum { Do Do } }
{ c' d' }
\addlyrics \letraUno
\addlyrics \letraDos
% %%%END
I cannot verify the issue. Lilypond crashes when I try.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \grace after \cadenzaOff suppresses auto-beams
And I just found a solution that works even better for me...
%%% previous stuff
\cadenzaOff
\bar "|"
\appoggiatura b4
\set Timing.measurePosition = #(ly:make-moment 0 4)
%%% subsequent stuff
...by setting the measurePosition *after* the grace/appoggiatura and
before the first "beat" of the measure, the beams remain intact and
the warning disappears. Huzzah.
But still "strange" if you consider the bar numbering (the same goes
with your accidentals' problem):
\relative c' {
\override Score.BarNumber #'break-visibility = #'#(#t #t #t)
\set Score.currentBarNumber = #11
\bar ""
\time 2/4
c2
\cadenzaOn
c2 d8-[ e \bar "|" f g-]
\cadenzaOff
\bar "|"
\grace b8 \bar "|"
a4. \bar "|" gis8 \bar "|"
e'8 \bar "|" e \bar "|" e \bar "|" e
}
Cheers,
Jean-Charles
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
>> >> Normal from what perspective? Where it left off before \cadenzaOn or >> simply that it starts back at '0' immediately \cadenzaOff >> >> I'm wondering if we need something (a sentence of two) in the NR to >> avoid what is obviously something that does confuse people. > > I still have not figured out the exact reasoning behind this. But it > does not seem to be much more than "stop advancing time in measure" > "start advancing time in measure again". If there is no material left > to fill the bar, the measure will not get full. Actually, it resets timing to 0, so even if the bar has some notes before \cadenzaOn, they don't get counted toward the timing once \cadenzaOff is reached. So it is not "stop advancing time in measure to resume later", but rather "stop counting altogether and then reset to 0." I would think that once the timing is reset to 0, as \cadenzaOn does, it should automatically insert a barline at that point and treat the subsequent material as a new measure (thus avoiding problems with accidentals). I really think this is a design flaw. -- Neil Thornock, D.M. No Stopping, Standing, or Parking: http://neilthornock.net/mp3s/nostopping.mp3 Assistant Professor of Music Composition/Theory Brigham Young University ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1128 in lilypond: Text pedal mark not closed at music end
Comment #7 on issue 1128 by philehol...@gmail.com: Text pedal mark not closed at music end http://code.google.com/p/lilypond/issues/detail?id=1128 Bounty of 50 GBP for this one. Pedal closing marks are generally not placed well - the code: c''1_\sustainOn c''1_\sustainOff gives the attached image - the * is far too far to the right - it should be on the bar line. Attachments: PedalEnding.png 1.8 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2344 in lilypond: Kievan final barline gets cut off
Comment #8 on issue 2344 by aleksandr.andr...@gmail.com: Kievan final barline gets cut off http://code.google.com/p/lilypond/issues/detail?id=2344 Changing the dimensions of char_box only moves the bar line around on the staff. There should be a way of implementing what \stopStaff does. But unfortunately, \stopStaff is not supported for bar lines :(. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2344 in lilypond: Kievan final barline gets cut off
Comment #7 on issue 2344 by janek.li...@gmail.com: Kievan final barline gets cut off http://code.google.com/p/lilypond/issues/detail?id=2344 I thought that \override Staff.BarLine #'X-offset = #'(10 . 0) might help but it doesn't work. Have you tried making the char_box too wide (either to the left or to the right)? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2333 in lilypond: extract-texi-filenames doesn't ignore comments
Updates: Status: Fixed Labels: -Patch-push Fixed_2_15_33 Comment #10 on issue 2333 by philehol...@gmail.com: extract-texi-filenames doesn't ignore comments http://code.google.com/p/lilypond/issues/detail?id=2333 Pushed to staging as fe2e679d876eba72077a9ced1b918ad330e79bb4 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
On 3/5/2012 4:41 PM, David Kastrup wrote:
James writes:
Hello,
On 5 March 2012 15:20, David Kastrup wrote:
Neil Thornock writes:
In my mind, the real bug is that \cadenzaOff does not seem to turn the
cadenza off immediately, but rather one measure later. I'm not sure
why it behaves as it does.
It resets timing to normal, and "normal" does not mean the end of a
measure.
Normal from what perspective? Where it left off before \cadenzaOn or
simply that it starts back at '0' immediately \cadenzaOff
I'm wondering if we need something (a sentence of two) in the NR to
avoid what is obviously something that does confuse people.
I still have not figured out the exact reasoning behind this. But it
does not seem to be much more than "stop advancing time in measure"
"start advancing time in measure again". If there is no material left
to fill the bar, the measure will not get full.
I've tried a couple things:
The first example uses Neil T's idea of setting \cadenzaOff a measure
before it ends. It is intentionally awkward timing-wise. Note that it
was necessary to used \cadenzaOff one note later than \cadenzaOn and
that I also had to add a skip to be sure the barline was in the right
place. It seems kludgy/ugly to me:
%%%
\version "2.14.2"
{
\time 4/4
c1
\cadenzaOn
c4 ~ \cadenzaOff c8 s32
c16-[ c c c-] c4 c32-[ c c c c c c-] c8
\bar "|"
c4 c4 c
}
%% This one tests David K's comment regarding
%% time stops/time starts
\relative c'
{
c1
c2 \cadenzaOn \teeny f32-[ a c f, a c f, a c-] \cadenzaOff
\normalsize c2
c1
}
%%%
The result I get from the second one strongly indicates that \cadenzaOn
means time stops but that \cadenzaOff means, "Once a full measure has
passed *from this point* the next one starts." If it was as simple as
time stops/starts (the way I'm intepreting it) then the first part of
measure two of the second example would be counted and the last half
would be counted and nothing inside the cadenza would be counted. This
is not what happens, though. It would be necessary to use 'c2*2' at the
end of that bar as David K suggested earlier. It works and is much less
ugly than the top example but strikes me as less than satisfactory.
I'm trying to avoid being a choosy beggar here as I certainly don't have
the programming chops to dig in and fix this myself. I suspect,
however, that "remembering" the portion of a measure preceding
\cadenzaOn and then adding it to what comes after \cadenzaOff could be
complicated. I can also easily imagine a situation where that approach
would fail. Instead, would it not be useful to have some way to signal
that the measure is over and a new measure is to begin, complete with
barline and accidental behavior? I can also well imagine a scenario
where having \cadenzaOff doing this would also fail. I'm thinking
something like '\endMeasure' to accomplish this. I know that's only
syntax and not a solution. I'm just wondering if leaving \cadenzaOn
\cadenzaOff as they are and having another mechanism take care of
initiating the next measure would be the solution.
In the meantime, I'll just have to remember these workarounds.
-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
James writes: > Hello, > > On 5 March 2012 15:20, David Kastrup wrote: >> Neil Thornock writes: >> >>> In my mind, the real bug is that \cadenzaOff does not seem to turn the >>> cadenza off immediately, but rather one measure later. I'm not sure >>> why it behaves as it does. >> >> It resets timing to normal, and "normal" does not mean the end of a >> measure. >> > > Normal from what perspective? Where it left off before \cadenzaOn or > simply that it starts back at '0' immediately \cadenzaOff > > I'm wondering if we need something (a sentence of two) in the NR to > avoid what is obviously something that does confuse people. I still have not figured out the exact reasoning behind this. But it does not seem to be much more than "stop advancing time in measure" "start advancing time in measure again". If there is no material left to fill the bar, the measure will not get full. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
Hello, On 5 March 2012 15:20, David Kastrup wrote: > Neil Thornock writes: > >> In my mind, the real bug is that \cadenzaOff does not seem to turn the >> cadenza off immediately, but rather one measure later. I'm not sure >> why it behaves as it does. > > It resets timing to normal, and "normal" does not mean the end of a > measure. > Normal from what perspective? Where it left off before \cadenzaOn or simply that it starts back at '0' immediately \cadenzaOff I'm wondering if we need something (a sentence of two) in the NR to avoid what is obviously something that does confuse people. Regards -- -- James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
"David Bobroff" wrote in message
news:4f547dc7.10...@centrum.is...
I'm re-framing my query regarding accidental behavior following
\cadenzaOff. After some discussion about this on bug- it is quite clear
that '\cadenzaOff' *only* affects counting/timing and '\bar' *only* paints
a graphic of a bar line. Currently, if an accidental appears in the
cadenza it will be visibly canceled if the key signature value of the note
is used in the next "measure" even if '\cadenzaOff \bar "|."' is present.
Musically this should not happen. Since a bar line has gone by the key
signature is back in force.
This post in on -user to see if anyone has a solution; how do I suppress
the accidental cancellation in the following example?
I've posted this to bug- to suggest that LilyPond should probably
understand this.
Example:
%%%
\version "2.14.2"
\relative c'
{
\key c \major
\time 2/4
c2 ~
\cadenzaOn
c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
\cadenzaOff
\bar "|"
e2 % how to suppress accidental cancellation here?
}
%%%
-David
Eluze added something about this as
http://code.google.com/p/lilypond/issues/detail?id=2379
Is that what was wanted?
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
In my mind, the real bug is that \cadenzaOff does not seem to turn the
cadenza off immediately, but rather one measure later. I'm not sure
why it behaves as it does.
In any case, I always turn the cadenza off a full measure before I
actually want it turned off.
On Mon, Mar 5, 2012 at 1:48 AM, David Bobroff wrote:
> I'm re-framing my query regarding accidental behavior following \cadenzaOff.
> After some discussion about this on bug- it is quite clear that
> '\cadenzaOff' *only* affects counting/timing and '\bar' *only* paints a
> graphic of a bar line. Currently, if an accidental appears in the cadenza
> it will be visibly canceled if the key signature value of the note is used
> in the next "measure" even if '\cadenzaOff \bar "|."' is present. Musically
> this should not happen. Since a bar line has gone by the key signature is
> back in force.
>
> This post in on -user to see if anyone has a solution; how do I suppress the
> accidental cancellation in the following example?
>
> I've posted this to bug- to suggest that LilyPond should probably understand
> this.
>
> Example:
>
> %%%
> \version "2.14.2"
>
> \relative c'
> {
> \key c \major
> \time 2/4
> c2 ~
> \cadenzaOn
> c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
> \cadenzaOff
> \bar "|"
> e2 % how to suppress accidental cancellation here?
> }
> %%%
>
> -David
>
> ___
> lilypond-user mailing list
> lilypond-u...@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
--
Neil Thornock, D.M.
No Stopping, Standing, or Parking:
http://neilthornock.net/mp3s/nostopping.mp3
Assistant Professor of Music
Composition/Theory
Brigham Young University
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2338 in lilypond: OS X LilyPad not working
Comment #40 on issue 2338 by colingh...@gmail.com: OS X LilyPad not working
http://code.google.com/p/lilypond/issues/detail?id=2338
Klaus Foegel reported on lilypond-user:
http://article.gmane.org/gmane.comp.gnu.lilypond.general/70477
http://article.gmane.org/gmane.comp.gnu.lilypond.general/70478
I'm a bit concerned that even with the plist fixed Klaus still has a
problem getting Lilypad to run.
I'm going to get some 10.4 users to run the new Lilypad app and confirm
that they have no issue launching it.
Klaus' post below:
Hello,
MacOS X x86: LilyPond 2.15.31-1 unpacked and installed on
Mac OS X Version 10.4.11 MacMini Intel Core Duo.
Adding the missing to a line including spaces in Info.plist,
after reboot proper Lilypond icon shows up. As per issue 2338.
Double-clicking on icon gives Error, no description in the Error Window,
Console log see below.
Regards
Klaus
P.S.
1) Similar post this morning did not come through, hence re-posting.
2) lilypond inside ...resources..bin... does work.
3) unavailable for testing next 2.7 weeks
Mac OS X Version 10.4.11 (Build 8S2167)
2012-03-04 21:37:44 +
2012-03-04 21:37:44.707 SystemUIServer[78] lang is:en
Mar 4 21:37:45 klaus-foehls-computer mDNSResponder: Adding
browse domain local.
Traceback (most recent call last):
File "/Users/kf/Desktop/testlily/LilyPond.app/Contents/Resou
rces/__boot__.py", line 31, in
_run('LilyPond.py')
File "/Users/kf/Desktop/testlily/LilyPond.app/Contents/Resou
rces/__boot__.py", line 28, in _run
execfile(path, globals(), globals())
File "/Users/kf/Desktop/testlily/LilyPond.app/Contents/Resou
rces/LilyPond.py", line 3, in
from PyObjCTools import AppHelper
File "PyObjCTools/AppHelper.pyc", line 14, in
File "AppKit/__init__.pyc", line 9, in
File "Foundation/__init__.pyc", line 10, in
File "CoreFoundation/__init__.pyc", line 21, in
File "CoreFoundation/_CoreFoundation.pyc", line 18, in
File "CoreFoundation/_CoreFoundation.pyc", line 11, in __load
ImportError: dlopen(/Users/kf/Desktop/testlily/LilyPond.app/Cont
ents/Resources/lib/python2.6/lib-dynload/CoreFoundation/_CoreFou
ndation.so, 2): Symbol not found: _CFFileDescriptorCreate
Referenced from: /Users/kf/Desktop/testlily/LilyPond.app/Conte
nts/Resources/lib/python2.6/lib-dynload/CoreFoundation/_CoreFoundation.so
Expected in: /System/Library/Frameworks/CoreFoundation.framewo
rk/CoreFoundation
2012-03-04 21:38:00.639 LilyPond[131] LilyPond Error
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 316 in lilypond: ancient \ictus not centered
Comment #5 on issue 316 by paconet@gmail.com: ancient \ictus not
centered
http://code.google.com/p/lilypond/issues/detail?id=316
To ease testing, here is an updated code for current development version.
\version "2.15.29"
\include "gregorian.ly"
\score {
<<
\new VaticanaVoice = "cantus" {
\override Script #'padding = #0
\clef "vaticana-do3"
\[ f\melisma f \pes g\melismaEnd \]
f
\[ f \ictus \]
\[ f \pes g\ictus \pes a \]
}
\new Lyrics \lyricsto "cantus" {
Re -- qui -- em ae-
}
>>
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Formatting of lyrics
2012/3/5 -Eluze :
> O.K. - see attachment - I am interested in the "R" at the end of even
>> verses (symbol "R" I've created).
gregorian.ly defines \ij \iij etc for prefixing and a two \responsum
and \versus functions which do not seem to work. However, the unicode
symbols used there still serve, see
\include "gregorian.ly"
{ c' }
\addlyrics { \set stanza = ℟ Do }
\addlyrics { \set stanza = ℣ Do }
Forwarding to bug-lilypond because this should workk but it doesn't:
% %%% BEGIN
\include "gregorian.ly"
letraUno = \lyricmode { \versus { Do Do } }
letraDos = \lyricmode { \responsum { Do Do } }
{ c' d' }
\addlyrics \letraUno
\addlyrics \letraDos
% %%%END
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \cadenzaOff and accidentals
David Bobroff writes:
> I'm re-framing my query regarding accidental behavior following
> \cadenzaOff. After some discussion about this on bug- it is quite
> clear that '\cadenzaOff' *only* affects counting/timing and '\bar'
> *only* paints a graphic of a bar line. Currently, if an accidental
> appears in the cadenza it will be visibly canceled if the key
> signature value of the note is used in the next "measure" even if
> \cadenzaOff \bar "|."' is present. Musically this should not happen.
> Since a bar line has gone by the key signature is back in force.
>
> This post in on -user to see if anyone has a solution; how do I
> suppress the accidental cancellation in the following example?
>
> I've posted this to bug- to suggest that LilyPond should probably
> understand this.
>
> Example:
>
> %%%
> \version "2.14.2"
>
> \relative c'
> {
> \key c \major
> \time 2/4
> c2 ~
> \cadenzaOn
> c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
> \cadenzaOff
> \bar "|"
> e2 % how to suppress accidental cancellation here?
> }
> %%%
>
> -David
\version "2.15.20"
\relative c'
{
\key c \major
\time 2/4
c2 ~
\cadenzaOn
c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
\cadenzaOff
\bar "|"
\once\accidentalStyle forget
e2 % how to suppress accidental cancellation here?
}
Note the version number. \once worked for complex stuff with 2.15.17,
and the \accidentalStyle syntax comes with 2.15.20. There will be
solutions for versions earlier than that, but I don't care getting
myself educated about them.
The real fix would be to mess with the Timing in a way that the \bar "|"
is not necessary. One way is to switch the cadenza off one note early
and let the last note take a full measure:
\relative c'
{
\key c \major
\time 2/4
c2 ~
\cadenzaOn c4 \teeny d8-[ es f g-]
\cadenzaOff \normalsize a4*2-\fermata
e2 % how to suppress accidental cancellation here?
}
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
\cadenzaOff and accidentals
I'm re-framing my query regarding accidental behavior following
\cadenzaOff. After some discussion about this on bug- it is quite clear
that '\cadenzaOff' *only* affects counting/timing and '\bar' *only*
paints a graphic of a bar line. Currently, if an accidental appears in
the cadenza it will be visibly canceled if the key signature value of
the note is used in the next "measure" even if '\cadenzaOff \bar "|."'
is present. Musically this should not happen. Since a bar line has
gone by the key signature is back in force.
This post in on -user to see if anyone has a solution; how do I suppress
the accidental cancellation in the following example?
I've posted this to bug- to suggest that LilyPond should probably
understand this.
Example:
%%%
\version "2.14.2"
\relative c'
{
\key c \major
\time 2/4
c2 ~
\cadenzaOn
c4 \teeny d8-[ es f g-] \normalsize a4-\fermata
\cadenzaOff
\bar "|"
e2 % how to suppress accidental cancellation here?
}
%%%
-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
