Le samedi 03 juin 2023 à 00:15 +0200, Heiko Schill a écrit :
> Good evening everyone,
>
> when compiling the attached document, in the first staff the clef change is
> ignored for the lower voice after moving the ottavation spanner to the
> voice context as suggested in the sn
Good evening everyone,
when compiling the attached document, in the first staff the clef change is
ignored for the lower voice after moving the ottavation spanner to the
voice context as suggested in the snippets-document. This seems to happen
only if one or more notes are located between the
> On 11 Oct 2020, at 16:33, Thomas Morley wrote:
>
> Am Sa., 10. Okt. 2020 um 16:14 Uhr schrieb Owain Evans :
>>
>> Hi Bug-Lily,
>>
>> MultiMeasureRest and "clef change at end of measure" events in different
>> staffs but sa
Am Sa., 10. Okt. 2020 um 16:14 Uhr schrieb Owain Evans :
>
> Hi Bug-Lily,
>
> MultiMeasureRest and "clef change at end of measure" events in different
> staffs but same measure: undesired MultiMeasureRest X position.
>
> MultiMeasureRest needs to be centered
Hi Bug-Lily,
MultiMeasureRest and "clef change at end of measure" events in different
staffs but same measure: undesired MultiMeasureRest X position.
MultiMeasureRest needs to be centered in this case.
I.e. The rest's centring between the two barlines presides over the additi
Hi squad,
See enclosed after E. Gould
See: http://lsr.di.unimi.it/LSR/Item?id=1110
(and:
http://lilypond.1069038.n5.nabble.com/Snippet-quot-Clef-change-and-repeat-barline-quot-td234216.html
)
Cheers,
PIerre
___
bug-lilypond mailing list
bug-lilypond
Malte Meyn-3 wrote
> That example is the same in the german translation. But at p. 172
> (“Horizontale Ausrichtung von Pausen → Ganztaktige Pausen”, i. e.
> “Horizontal positioning of rests → full measure rests”) she writes
> something like “If the rest measure contains a clef, key signature or
trument
had a clef change... Or maybe I don't get your point.
Yes, that’s what I find strange too.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Malte Meyn-3 wrote
> I think that it depends on context: In a full score where only one
> instrument has a clef change, it would look weird if all the other
> instruments have the rest not centered. But in solo music, I’m not so
> sure which one I would prefer.
>
>
Am Sa., 26. Okt. 2019 um 10:30 Uhr schrieb foxfanfare :
>
> Hi all,
>
> I think this is a bug: when a clef change appears after a full measure rest,
> the rest is no longer centered properly in the measure. The result looks
> weird. See that example:
>
> \version
Am 26.10.19 um 10:40 schrieb foxfanfare:
Hi all,
I think this is a bug: when a clef change appears after a full measure rest,
the rest is no longer centered properly in the measure. The result looks
weird. See that example:
\version "2.19.82"
\new Staff
\relative c' {
c
Hi all,
I think this is a bug: when a clef change appears after a full measure rest,
the rest is no longer centered properly in the measure. The result looks
weird. See that example:
\version "2.19.82"
\new Staff
\relative c' {
c1
R-"default"
\bar "||&qu
2017-10-11 21:56 GMT+02:00 Ophir Lifshitz :
> Hi Malte,
>
> Thank you very much for that cleaner workaround. Now I am mainly interested
> in making sure that this bug gets properly filed so that it can eventually
> be fixed.
>
> Ophir
Hi Ophir,
this has to do with how LilyPond deals with loose co
;>>>> On Tue, Oct 27, 2015 at 6:15 PM, Ophir Lifshitz <
>>>>> hangfromthefl...@gmail.com> wrote:
>>>>>
>>>>> And so in that case, probably something like \hideNotes r ...
>>>>>> \unHideNotes will be sufficient.
>>
27;m
still mostly convinced it's a bug that needs to be fixed.
For example, change the space s4. near the bottom of the file between
three eighth rests r r r (clef change is – mostly – properly spaced)
and two rests plus a space r r s (collision). It seems that Lilypond
can't detect the RH&#
ue, Oct 27, 2015 at 6:10 PM, Ophir Lifshitz <
>>>> hangfromthefl...@gmail.com> wrote:
>>>>
>>>>> Hello again,
>>>>>
>>>>> Yes, thank you Pierre. I believe that will work temporarily, but I'm
>>>>> stil
On 19.10.2016 18:59, Javier Ruiz-Alma wrote:
There's open issue matching the behavior...reported by Simon Albrecht back in
2013.
https://sourceforge.net/p/testlilyissues/issues/3287/
As a side note: If you surround your code examples on the sourceforge
tracker with
:::TeX
%% here come
On 19.10.2016 18:59, Javier Ruiz-Alma wrote:
There's open issue matching the behavior...reported by Simon Albrecht back in
2013.
https://sourceforge.net/p/testlilyissues/issues/3287/
The title of this could be more specific.
It’s now “Clefs at line change shorten slurs unduly”. That should b
There's open issue matching the behavior...reported by Simon Albrecht back in
2013.
https://sourceforge.net/p/testlilyissues/issues/3287/
The title of this could be more specific.
Javier
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://list
David Nalesnik writes:
> On Tue, Oct 18, 2016 at 4:56 PM, Javier Ruiz-Alma
> wrote:
>> The first segment of a slur that spans to the next system is typeset short
>> if a clef change is present at the end of the originating measure. The
>> first segment won'
2016-10-19 3:02 GMT+02:00 David Nalesnik :
> On Tue, Oct 18, 2016 at 4:56 PM, Javier Ruiz-Alma
> wrote:
>> The first segment of a slur that spans to the next system is typeset short
>> if a clef change is present at the end of the originating measure. The
>> first s
On Tue, Oct 18, 2016 at 4:56 PM, Javier Ruiz-Alma wrote:
> The first segment of a slur that spans to the next system is typeset short if
> a clef change is present at the end of the originating measure. The first
> segment won't overlap the space above the changed clef.
>
&
The first segment of a slur that spans to the next system is typeset short if a
clef change is present at the end of the originating measure. The first
segment won't overlap the space above the changed clef.
Javier Ruiz-Alma
\version "2.18.2"
\score {
<<
{ c&
27, 2015 at 6:10 PM, Ophir Lifshitz <
>>> hangfromthefl...@gmail.com> wrote:
>>>
>>>> Hello again,
>>>>
>>>> Yes, thank you Pierre. I believe that will work temporarily, but I'm
>>>> still mostly convinced it's a bug
;> On Tue, Oct 27, 2015 at 6:10 PM, Ophir Lifshitz <
>> hangfromthefl...@gmail.com> wrote:
>>
>>> Hello again,
>>>
>>> Yes, thank you Pierre. I believe that will work temporarily, but I'm
>>> still mostly convinced it's a bug that needs
vinced it's a bug that needs to be fixed.
>>
>> For example, change the space s4. near the bottom of the file between
>> three eighth rests r r r (clef change is – mostly – properly spaced) and
>> two rests plus a space r r s (collision). It seems that Lilypond can&
;s a bug that needs to be fixed.
>
> For example, change the space s4. near the bottom of the file between
> three eighth rests r r r (clef change is – mostly – properly spaced) and
> two rests plus a space r r s (collision). It seems that Lilypond can't
> detect the RH'
Hello again,
Yes, thank you Pierre. I believe that will work temporarily, but I'm still
mostly convinced it's a bug that needs to be fixed.
For example, change the space s4. near the bottom of the file between three
eighth rests r r r (clef change is – mostly – properly spaced) and
cis8_3
}
>>
2015-10-27 22:37 GMT+01:00 Ophir Lifshitz :
> Hi Pierre,
>
> I'm afraid that override only makes the issue worse by shifting the clef
> left. I might have been unclear, but the clef change belongs after note 2
> and directly before the sharped note 3, and
Hi Pierre,
I'm afraid that override only makes the issue worse by shifting the clef
left. I might have been unclear, but the clef change belongs after note 2
and directly before the sharped note 3, and not in the small space between
notes 1 and 2. Shifting it left makes it look like note
gt; The notes labeled 1 and 2 on the lower LH staff are both notated in treble
> clef. But because space wasn't made for the bass clef change, the bass clef
> misleadingly appears slightly before note 2. I would have instead expected
> to see a lot of space made between notes 2 and 3 w
Hello all,
I believe there is a bug in making space for clef changes. You can find the
MWE here: http://lilybin.com/gs2oks/7
The notes labeled 1 and 2 on the lower LH staff are both notated in treble
clef. But because space wasn't made for the bass clef change, the bass clef
misleadingly ap
> %%% Commenting out the following line solves the problem %%%
> \clef bass
> e fis d c
>}
>\layout {}
> }
>
> The clef change causes lilypond to error and not produce output. This also
> errors in 2.15., while 2.12 does not error. Is there some way
james writes:
> Honestly, what's most important to me is where the sharps/flats in the
> key signature are placed. I attach the image of what I expect:
That image does not make sense to me at all. Notes appear in key
signature (though in a different octave) and still carry an accidental.
How do
t being fixed to
> a certain octave concerning their effect on the music.
>
> However, with _that_ interpretation, a clef change like you propose
> above leads to accidentals displayed up in the sky in ledger line
> domain. What's the key engraver to do in this case? Transpose t
}
\layout {}
}
The clef change causes lilypond to error and not produce output. This also
errors in 2.15., while 2.12 does not error. Is there some way around this?
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailm
line solves the problem %%%
> \clef bass
> e fis d c
>}
>\layout {}
> }
>
> The clef change causes lilypond to error and not produce output. This
> also errors in 2.15., while 2.12 does not error. Is there some way
> around this?
Ok, consider me annoyed
Updates:
Status: Verified
Comment #11 on issue 1695 by philehol...@googlemail.com: Clef change placed
outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
(No comment was entered for this change.)
___
bug-lilypond mailing
Comment #10 on issue 1695 by carl.d.s...@gmail.com: Clef change placed
outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
Backported
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug
Updates:
Labels: -backport fixed_2_14_2
Comment #9 on issue 1695 by carl.d.s...@gmail.com: Clef change placed
outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
Backported
___
bug-lilypond mailing list
bug-lilypond
Updates:
Status: Fixed
Labels: -Patch-review -CD-110718 fixed_2_15_6 backport
Comment #8 on issue 1695 by n.putt...@gmail.com: Clef change placed outside
score
http://code.google.com/p/lilypond/issues/detail?id=1695
bebd93c2dd0d7363f311d912ec1ed1f7dfcb36ba
Updates:
Labels: CD-110718
Comment #7 on issue 1695 by colinpkc...@gmail.com: Clef change placed
outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
(No comment was entered for this change.)
___
bug-lilypond mailing list
Updates:
Labels: Patch-review
Comment #6 on issue 1695 by n.putt...@gmail.com: Clef change placed outside
score
http://code.google.com/p/lilypond/issues/detail?id=1695
Patch: http://codereview.appspot.com/4683043/
___
bug-lilypond mailing
Updates:
Status: Started
Owner: n.putt...@gmail.com
Comment #5 on issue 1695 by n.putt...@gmail.com: Clef change placed outside
score
http://code.google.com/p/lilypond/issues/detail?id=1695
(No comment was entered for this change
Comment #4 on issue 1695 by n.putt...@gmail.com: Clef change placed outside
score
http://code.google.com/p/lilypond/issues/detail?id=1695
1d4914c023a672e0e80b9b9eafc123605f4c0f00 is the first really bad commit (my
initial commit is also a bit weird, but it's the tempo mark whi
Comment #3 on issue 1695 by percival.music.ca: Clef change placed outside
score
http://code.google.com/p/lilypond/issues/detail?id=1695
the problem occurred between
BAD:
9a63326816f586dd79d326776583697f95203330
and GOOD:
d3d40f3469eda2cb327bebbd392c1ce88b114394
but unfortunately the
Comment #2 on issue 1695 by reinhold...@gmail.com: Clef change placed
outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
I can confirm it too, here on linux.
If the regression occurred between 2.13.31 and .34, then my bet is that
Jan's work on the Metronome-mark (a
On Wed, Jun 15, 2011 at 6:11 AM, Ralph Palmer wrote:
> This has been submitted as Issue 1695 :
> http://code.google.com/p/lilypond/issues/detail?id=1695
Thanks. I think I found a couple workarounds:
musy = \relative c'
{
\clef treble
\override Score.NonMusicalPaperColumn #'allow-loose-spaci
Updates:
Labels: -Priority-High Priority-Critical Regression
Comment #1 on issue 1695 by philehol...@googlemail.com: Clef change placed
outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
Confirmed on my windows box. Regression occurred between 2.13.31 and 13.34
On Tue, Jun 14, 2011 at 11:55 PM, Jay Anderson wrote:
> \version "2.14.1"
>
> %The bass clef in the lower staff is placed to the left of the staff. If
> either
> %the tempo mark is removed or the triplets are changed to a quarter note
> the
> %the clef is placed correctly. This was not an error i
Status: Accepted
Owner:
Labels: Type-Defect Priority-High
New issue 1695 by ralphbug...@gmail.com: Clef change placed outside score
http://code.google.com/p/lilypond/issues/detail?id=1695
I cannot confirm this problem. No matter how I try to open or edit the .ly
file (in ConTEXT or in
\version "2.14.1"
%The bass clef in the lower staff is placed to the left of the staff. If either
%the tempo mark is removed or the triplets are changed to a quarter note the
%the clef is placed correctly. This was not an error in 2.12.3.
musx = \relative c'
{
% Change this to c4 for correct cl
Updates:
Status: Verified
Comment #15 on issue 1471 by philehol...@googlemail.com: accidentals after
a clef change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
(No comment was entered for this change.)
___
bug
Updates:
Status: Fixed
Labels: -Patch-review fixed_2_13_60
Comment #14 on issue 1471 by percival.music.ca: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
pushed in
9ee41ab7352ca3df7aa2ddd8e7097660924f3e36
Updates:
Labels: -Patch-needs_work Patch-review
Comment #13 on issue 1471 by percival.music.ca: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
The difference is that now I can say that you've done absolutely everything
Comment #12 on issue 1471 by d...@gnu.org: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
I can't really see that this makes any sense or difference, but in order
not to be declared the cause for bit rot, here you are.
Updates:
Labels: -Patch-review Patch-needs_work
Comment #11 on issue 1471 by percival.music.ca: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
In light of the confusion about call_context_property_on_children (), and
the lack
Comment #10 on issue 1471 by d...@gnu.org: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
There is no function call_context_property_on_children. There is no
evaluation of "the function" (by which you probably mean SCM fu
Comment #9 on issue 1471 by n.putt...@gmail.com: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
+static void apply_on_children (Context *context, SCM fun)
This evaluates the function each time it's recursed; why not instea
Updates:
Labels: -Patch-new Patch-review
Comment #8 on issue 1471 by colinpkc...@gmail.com: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
Clean compile and regtest.
___
bug
Updates:
Labels: Patch-new
Comment #7 on issue 1471 by percival.music.ca: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
A countdown is the appropriate way to absolve yourself of any possible
complaint from people who didn&#
Comment #6 on issue 1471 by d...@gnu.org: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
Due to me messing up with git, you can now conveniently apply the above
patch using
git cherry-pick 197e3ae339
and take a look at it using
Comment #5 on issue 1471 by d...@gnu.org: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
Ok, I think I have a candidate for merging. I made use of the
infrastructure for accidentals tied into a new bar (which also need a
Comment #4 on issue 1471 by d...@gnu.org: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
Ok, here is the full job which passes the regtest without difference in
output, but produces the following image for the test file of this bug
Comment #3 on issue 1471 by k-ohara5...@oco.net: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
The concept behind the half patch is described at :
http://lists.gnu.org/archive/html/lilypond-user/2011-04/msg00038.html
Myself, I won&#
Comment #2 on issue 1471 by d...@gnu.org: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
Here is a patch that should do half the job. Can anybody make it do the
full job?
Attachments:
invalidate-alterations-on-clef
> is.
>
> % When there is a clef change within a measure, we want cancellation
> accidentals to
> % be printed, if they would be printed for the same pitches without the clef
> change.
[...]
Thank you, this was added as 1471:
On Tue 11 Jan 2011, 19:42 lilyp...@googlecode.c
Comment #1 on issue 1471 by brownian.box: accidentals after a clef change
are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
(for the record) Keith also pointed to the discussion:
http://lists.gnu.org/archive/html/bug-lilypond/2010-12/msg00403.html
Status: Accepted
Owner:
Labels: Type-Defect Priority-Low
New issue 1471 by jameseli...@googlemail.com: accidentals after a clef
change are not printed
http://code.google.com/p/lilypond/issues/detail?id=1471
Accidentals after a clef change are not printed and should be.
\version "2
Dear bug squad,
I am rephrasing a report that got lost in a long-ish thread
<http://lists.gnu.org/archive/html/bug-lilypond/2010-12/msg00403.html>
discussing whether it was really a bug. The thread eventually made clear: it
is.
% When there is a clef change within a measure, w
I think the rule is thus. Clefs shall have no effect on accidentals
and therefore notes after the clef change are altered by courtesy
accidentals for ease of legibility or where the note occurs in a
different octave which requires, in strict notation, its own
accidental. On the reasoning that they
Am Dienstag, 28. Dezember 2010, um 15:44:22 schrieb Reinhold Kainhofer:
> Am Dienstag, 28. Dezember 2010, um 15:14:05 schrieb David Kastrup:
> > Reinhold Kainhofer writes:
> > > I would be great, though, if anyone can find a published example of
> > > such a situation (most likely in e.g. cello/ba
embered to the end of
> the measure in which they occur and only in their own octave. Thus, in the
> example below, no natural signs are printed before the b in the second
> measure or the last c:
No, this is not the same case.
In NR 1.1.3 there is no clef change.
And according to th
On Dec 28, 2010, at 11:53 AM, Xavier Scheuer wrote:
> Hi!
>
> This has been reported on the French user mailing list.
>
> In the following code the c-natural is not printed if there is a clef
> change in the middle of the measure.
>
> \relative c' {
> \clef
clef changes 4 times (bass, treble, bass,
> treble). The movement is in E major. There is a natural sign on the A
> immediately after the clef change. It's not clear, though, whether it's
> there to cancel the sharp on the space (implied by the preceding C-sharp in
> th
Am Dienstag, 28. Dezember 2010, um 15:14:05 schrieb David Kastrup:
> Reinhold Kainhofer writes:
> > I would be great, though, if anyone can find a published example of such
> > a situation (most likely in e.g. cello/bassoon parts/scores, which
> > frequently switch between bass and tenor clef).
>
g-lilypond" ; "lilypond-user"
>
> Cc: "Philhar"
> Sent: Tuesday, December 28, 2010 10:53 AM
> Subject: Accidental and clef change issue
>
>
> Hi!
>
> This has been reported on the French user mailing list.
>
> In the following code
"Phil Holmes" writes:
> "David Kastrup" wrote in message
> news:87aajqowbn@lola.goethe.zz...
>> "Phil Holmes" writes:
>>
>>>
>>> Apologies. As you're probably aware, I'm a Windows man, and some
>>> postings don't quote properly using my mailreader.
>>
>> I am sure that there are sensible co
a
line of its own).
Good tip.
Now to your comment:
It's doing what I would expect from reading the regtest - i.e. - when
there is a clef change, the accidentals are reset to that which you'd
expect from the key. Therefore, in your example we return to C major,
and so there's no need
Reinhold Kainhofer writes:
> Am Dienstag, 28. Dezember 2010, um 14:23:14 schrieb Phil Holmes:
>> "David Kastrup" wrote in message
>> > I don't think it is correct. If you set the above with \key g\major,
>> > you will notice that the key signature is _
Am Dienstag, 28. Dezember 2010, um 14:23:14 schrieb Phil Holmes:
> "David Kastrup" wrote in message
> > I don't think it is correct. If you set the above with \key g\major,
> > you will notice that the key signature is _not_ repeated with a clef
> > chang
signs there, I have to put them in by
> hand. In this case, I didn't bother.
You should at the very least delete the signature marker ("-- " on a
line of its own).
>> Now to your comment:
>>
>>> It's doing what I would expect from reading the reg
ult, If I want all the >
signs there, I have to put them in by hand. In this case, I didn't bother.
Now to your comment:
It's doing what I would expect from reading the regtest - i.e. - when
there is a clef change, the accidentals are reset to that which you'd
expect from th
le mailreaders don't quote the signature
when replying, cutting away all of your content.
Now to your comment:
> It's doing what I would expect from reading the regtest - i.e. - when
> there is a clef change, the accidentals are reset to that which you'd
> expect from the
Hello,
- Original Message -
From: "Xavier Scheuer"
To: "bug-lilypond" ; "lilypond-user"
Cc: "Philhar"
Sent: Tuesday, December 28, 2010 10:53 AM
Subject: Accidental and clef change issue
Hi!
This has been reported on the French user ma
Hi!
This has been reported on the French user mailing list.
In the following code the c-natural is not printed if there is a clef
change in the middle of the measure.
\relative c' {
\clef bass cis2 c
\clef tenor cis2 \clef bass c % natural is not printed!!
\clef bass cis2 \clef te
gt; single rests (especially if there are multiple staves).
>
> Ahm, no, I don't think we want this before a clef change, because, here
> again, the rest will collide with the clef. See attached file...
Okay, to clarity: In general, we want single rests spaced to barlines --
unle
On 31 July 2010 13:06, Reinhold Kainhofer wrote:
> Ahm, no, I don't think we want this before a clef change, because, here again,
> the rest will collide with the clef. See attached file...
But if there's no time signature on the left hand side, it will look weird.
I can&
Am Freitag, 30. Juli 2010, um 21:30:26 schrieben Sie:
> On 30 July 2010 19:34, Reinhold Kainhofer wrote:
> > If a multi-measure rest is followed by a clef change, they will collide
> > as the attached example shows.
>
> Ah, good catch, Reinhold. :)
>
> The default fo
On 30 July 2010 19:34, Reinhold Kainhofer wrote:
> If a multi-measure rest is followed by a clef change, they will collide as the
> attached example shows.
Ah, good catch, Reinhold. :)
The default for 'spacing-pair isn't ideal for compressed rests: it
spaces the rest to the b
If a multi-measure rest is followed by a clef change, they will collide as the
attached example shows.
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial
nstead of remaining behind the barline. When I take out the grace
notes from the upper staff, the clef change happens as expected. Is
this a bug?
Actually, I like this behaviour. It uses the horizontal space in an
optimal way. However, I don't know whether this `solution' is
inte
> Notice how in the lower staff when the clef changes from alto to
> treble, the treble clef is shoved all the way into the next bar
> instead of remaining behind the barline. When I take out the grace
> notes from the upper staff, the clef change happens as expected. Is
> this a
Thanks. I should have seen this before. Sorry for the trouble...
Jon
Wilbert Berendsen wrote:
I think this is caused by grace timing. As a workaround you could add a \grace
s4 in the second staff, the clef change is behind the bar line.
See also
http://lilypond.org/doc/v2.11/Documentation
Op vrijdag 10 oktober 2008, schreef Wilbert Berendsen:
> I think this is caused by grace timing. As a workaround you could add a
> \grace s4 in the second staff, the clef change is behind the bar line.
I meant 'before' :-)
best regards,
Wilbert Berendsen
--
LilyKDE, LilyPo
I think this is caused by grace timing. As a workaround you could add a \grace
s4 in the second staff, the clef change is behind the bar line.
See also
http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Grace-notes
under Known issues and warnings.
<<
\new StaffGroup = &q
While working on a project recently I noticed odd behavior in a clef
change in the middle of a system. At the time, I just hacked around it
by adding another voice with nothing but skips and making sure there was
a "s32" after the clef change, but I thought I should report this jus
Issue 467: Two calls to set-octavation confound intervening clef change
http://code.google.com/p/lilypond/issues/detail?id=467
Comment #9 by v.villenave:
(No comment was entered for this change.)
Issue attribute updates:
Status: Verified
--
You received this message because you are
Issue 467: Two calls to set-octavation confound intervening clef change
http://code.google.com/p/lilypond/issues/detail?id=467
Comment #8 by joeneeman:
(No comment was entered for this change.)
Issue attribute updates:
Status: Fixed
Labels: fixed_2_11_38
--
You received this
Issue 467: Two calls to set-octavation confound intervening clef change
http://code.google.com/p/lilypond/issues/detail?id=467
Comment #7 by gpermus:
(No comment was entered for this change.)
Issue attribute updates:
Labels: -fixed_2_11_38
--
You received this message because you are
1 - 100 of 138 matches
Mail list logo
