Re: Shifting ottavation spanner to voice context breaks clef change in 2.24.0 and higher

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

Shifting ottavation spanner to voice context breaks clef change in 2.24.0 and higher

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

Re: Undesired MultiMeasureRest X position when clef change at end of measure

> 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

Re: Undesired MultiMeasureRest X position when clef change at end of measure

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

Undesired MultiMeasureRest X position when clef change at end of measure

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

Clef change and repeat sign

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

Re: Clef change and measure length

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

Re: Clef change and measure length

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

Re: Clef change and measure length

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. > >

Re: Clef change and measure length

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

Re: Clef change and measure length

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

Clef change and measure length

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 "||"

Re: Bad clef change collision when alternating piano staves

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

Re: Bad clef change collision when alternating piano staves

> >>>>> 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

Re: Bad clef change collision when alternating piano staves

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'

Re: Bad clef change collision when alternating piano staves

;>>> >>>> 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

Re: Broken slurs won't overlap end-of-measure clef change

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

Re: Broken slurs won't overlap end-of-measure clef change

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

Re: Broken slurs won't overlap end-of-measure clef change

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

Re: Broken slurs won't overlap end-of-measure clef change

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

Re: Broken slurs won't overlap end-of-measure clef change

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

Broken slurs won't overlap end-of-measure clef change

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'

Re: Bad clef change collision when alternating piano staves

>>> >>> 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

Re: Bad clef change collision when alternating piano staves

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 >>

Re: Bad clef change collision when alternating piano staves

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

Re: Bad clef change collision when alternating piano staves

>> 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

Bad clef change collision when alternating piano staves

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

Re: Bad clef change collision when alternating piano staves

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

Re: Bad clef change collision when alternating piano staves

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 >

Re: Bad clef change collision when alternating piano staves

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

Re: Bad clef change collision when alternating piano staves

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

Re: clef change confuses manual key signature

%%% \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

clef change confuses manual key signature

{} } 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

Re: clef change confuses manual key signature

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

Re: clef change confuses manual key signature

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Re: Clef change placed outside score

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

Re: Issue 1695 in lilypond: Clef change placed outside score

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

Clef change placed outside score

\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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: Issue 1471 in lilypond: accidentals after a clef change are not printed

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

Re: missing accidental after clef change

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

Issue 1471 in lilypond: accidentals after a clef change are not printed

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

missing accidental after clef change

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

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 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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

-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

Re: Accidental and clef change issue

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

Re: Accidental and clef change issue

, 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

Re: Multi-measure rest collides with clef change

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

Re: Multi-measure rest collides with clef change

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

Re: Multi-measure rest collides with clef change

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

Multi-measure rest collides with clef change

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

Re: Multi-measure rest collides with clef change

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

Grace notes cause clef-change positioning problem

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

Re: Grace notes cause clef-change positioning problem

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

Re: Grace notes cause clef-change positioning problem

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

Re: Grace notes cause clef-change positioning problem

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

Re: Grace notes cause clef-change positioning problem

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

Re: Grace notes cause clef-change positioning problem

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 in lilypond: Two calls to set-octavation confound intervening clef change

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 in lilypond: Two calls to set-octavation confound intervening clef change

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 in lilypond: Two calls to set-octavation confound intervening clef change

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 in lilypond: Two calls to set-octavation confound intervening clef change

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 in lilypond: Two calls to set-octavation confound intervening clef change

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 in lilypond: bar number positioning influenced by clef change at end of previous system

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   2   >