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
> 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 addition of
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
nt
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' {
c1
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 "||"
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
>
>>>>> 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.
&g
orarily, 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 two rests plus a space r r s (collision). It seems that Lilypond
can't detect the RH'
;>>>
>>>> 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
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
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
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
David Nalesnik <david.nales...@gmail.com> writes:
> On Tue, Oct 18, 2016 at 4:56 PM, Javier Ruiz-Alma <jav...@ruiz-alma.com>
> wrote:
>> The first segment of a slur that spans to the next system is typeset short
>> if a clef change is present at the
2016-10-19 3:02 GMT+02:00 David Nalesnik <david.nales...@gmail.com>:
> On Tue, Oct 18, 2016 at 4:56 PM, Javier Ruiz-Alma <jav...@ruiz-alma.com>
> wrote:
>> The first segment of a slur that spans to the next system is typeset short
>> if a clef change is present
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''2 c'
>>>
>>> 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 mostl
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
>>
ut 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
>> two rests plus a space r r s (collision). It seems
>>
2015-10-27 22:37 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>:
> 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 sharp
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 appears
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 appears slightly before note 2. I would have instead expected
> to see a lot of space
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
>
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 2
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 two
rests
%%%
\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 now. Yes, we have some snippets documenting
this sort
{}
}
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/mailman/listinfo/bug
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 the
whole octave-enriched
james james.lilyp...@googlemail.com 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
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
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: -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
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: 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
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 which
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 #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
On Tue, Jun 14, 2011 at 11:55 PM, Jay Anderson horndud...@gmail.com 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
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 Wed, Jun 15, 2011 at 6:11 AM, Ralph Palmer ralphbugl...@gmail.com 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
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
\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
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 #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
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't
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
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 instead use
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 fun), just
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 #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.
URL:http
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
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 #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
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't
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
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.com wrote:
Status: Accepted
Owner:
Labels
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.12.3
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, we want
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
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 reinh...@kainhofer.com writes:
I would be great, though, if anyone can find a published example of
such a situation (most likely in
are remembered 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 this rule
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 bass cis2 c
\clef tenor cis2 \clef bass c
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 tenor c
Hello,
- Original Message -
From: Xavier Scheuer x.sche...@gmail.com
To: bug-lilypond bug-lilypond@gnu.org; lilypond-user
lilypond-u...@gnu.org
Cc: Philhar philhar1...@orange.fr
Sent: Tuesday, December 28, 2010 10:53 AM
Subject: Accidental and clef change issue
Hi!
This has been
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 key. Therefore, in your example we return to C
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 the key. Therefore, in your example we
own).
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 to print the accidental. I'd
Am Dienstag, 28. Dezember 2010, um 14:23:14 schrieb Phil Holmes:
David Kastrup d...@gnu.org 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
change. So there is no visual or logical
with a clef
change. So there is no visual or logical reason to assume accidentals
are reset. If that was the underlying assumption for a clef change,
the key signature would be repeated.
So I'm confused as to what the regtest text cited means. It
(accidental-clef-change.ly) says Accidentals
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 to print the accidental. I'd welcome other
thoughts
Phil Holmes m...@philholmes.net writes:
David Kastrup d...@gnu.org wrote in message
news:87aajqowbn@lola.goethe.zz...
Phil Holmes m...@philholmes.net 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
-user
lilypond-u...@gnu.org
Cc: Philhar philhar1...@orange.fr
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 the c-natural is not printed if there is a clef
change
Am Dienstag, 28. Dezember 2010, um 15:14:05 schrieb David Kastrup:
Reinhold Kainhofer reinh...@kainhofer.com 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
, the 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
the bass clef) or whether it's
Am Freitag, 30. Juli 2010, um 21:30:26 schrieben Sie:
On 30 July 2010 19:34, Reinhold Kainhofer reinh...@kainhofer.com 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
On 31 July 2010 13:06, Reinhold Kainhofer reinh...@kainhofer.com 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't
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 --
unless the rest is too close to a subsequent clef change. I don't
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 Math
On 30 July 2010 19:34, Reinhold Kainhofer reinh...@kainhofer.com 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
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 just
in case
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 = strings
\new
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, LilyPond for KDE: http
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
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 bug?
Actually, I
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
intentionally selected by lilypond or caused
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
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
Issue 467: Two calls to set-octavation confound intervening clef change
http://code.google.com/p/lilypond/issues/detail?id=467
Comment #5 by joeneeman:
See the attachments to 533 for patches fixing this bug (parts 1, 6 and
7 of the
patch set, I think).
Issue attribute updates:
Status
Issue 467: Two calls to set-octavation confound intervening clef change
http://code.google.com/p/lilypond/issues/detail?id=467
Comment #6 by v.villenave:
Thanks a LOT! This was really an annoying bug (speaking from personal
experience).
I'll verify it as soon as I can.
Issue attribute
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
Issue 412: bar number positioning influenced by clef change at end of
previous system
http://code.google.com/p/lilypond/issues/detail?id=412
Comment #1 by joeneeman:
(No comment was entered for this change.)
Issue attribute updates:
Status: Fixed
Labels: fixed_2_11_35
--
You
1 - 100 of 129 matches
Mail list logo