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

[Jean Abou Samra]

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 snippets-document. This seems to happen
> only if one or more notes are located between the "\ottava 0" and the
> "\clef bass" command (see the third staff which compiles correctly).
> 
> In the default setup (second staff), the ottavation and clef change work
> correctly, but the ottavation is applied to all voices in the staff (as by
> design, but not intended here).
> 
> The usage of several voices is not necessary: In a single voice example,
> the bug manifests irrespective of the presence of extra notes between the
> \ottava and \clef commands (see staffs 4 and 5).
> 
> I noticed this behavior with version 2.24.0, but it is the same with
> version 2.24.1 and 2.25.5.


Thanks for the detailed report, and sorry for the delay in handling it. I've 
opened https://gitlab.com/lilypond/lilypond/-/issues/6633




signature.asc
Description: This is a digitally signed message part

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

[Heiko Schill]

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 "\ottava 0" and the
"\clef bass" command (see the third staff which compiles correctly).

In the default setup (second staff), the ottavation and clef change work
correctly, but the ottavation is applied to all voices in the staff (as by
design, but not intended here).

The usage of several voices is not necessary: In a single voice example,
the bug manifests irrespective of the presence of extra notes between the
\ottava and \clef commands (see staffs 4 and 5).

I noticed this behavior with version 2.24.0, but it is the same with
version 2.24.1 and 2.25.5.

Best regards,
Heiko
\version "2.25.5"

\markup \left-column {
"The change to bass clef is ignored for the lower voice here, when the" "ottavation spanner is moved from the staff- to the voice-context."
}

\score {
  \layout {
\context {
  \Staff
  \remove Ottava_spanner_engraver
}
\context {
  \Voice
  \consists Ottava_spanner_engraver
}
  }
  \new Staff
  <<
\new Voice { \clef treble { \relative c' { \voiceOne c'2 c4 c | \clef bass a,1 } } }
\new Voice { \clef treble { \relative c' { \voiceTwo d2 \ottava -1 d,4 \ottava 0 d' | \clef bass d,1 } } }
  >>  
}

\markup \left-column {
"With the default setup the example compiles correctly, but the" "ottavation entered in the lower voice is applied to both voices" "since the ottavation spanner is added to the staff context."
}

\score {
  \new Staff = "one"
  <<
\new Voice = "first" { \clef treble { \relative c' { \voiceOne c'2 c4 c | \clef bass a,1 } } }
\new Voice = "second" { \clef treble { \relative c' { \voiceTwo d2 \ottava -1 d,4 \ottava 0 d' | \clef bass d,1 } } }
  >>
}

\markup \left-column {
"This example compiles correctly, even with the ottavation spanner moved from the" "staff- to the voice-context."
}

\score {
  \layout {
\context {
  \Staff
  \remove Ottava_spanner_engraver
}
\context {
  \Voice
  \consists Ottava_spanner_engraver
}
  }
  \new Staff = "two"
  <<
\new Voice = "first" { \clef treble { \relative c' { \voiceOne c'2 c4 c | \clef bass a,1 } } }
\new Voice = "second" { \clef treble { \relative c' { \voiceTwo d2 d4  \ottava -1 d, \ottava 0 | \clef bass d1 } } }
  >>  
}

\markup \left-column {
"The bug manifests itself also in a single voice example, but here it does not matter"
"if notes are located between the \ottava and \clef commands."
}

\score {
  \layout {
\context {
  \Staff
  \remove Ottava_spanner_engraver
}
\context {
  \Voice
  \consists Ottava_spanner_engraver
}
  }
  \new Staff {
\clef treble { \relative c' { d2 d4  \ottava -1 d, \ottava 0 | \clef bass d1 } }
  }
}

\markup \left-column {
"This is the intended result with the default setup"
}
\score {
  \new Staff {
\clef treble { \relative c' { d2 d4  \ottava -1 d, \ottava 0 | \clef bass d1 } }
  }
}

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

[Owain Evans]

> 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 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 the clef symbol.
>> 
>> Gould p. 160: says "When the rest bar contains a clef, key signature or time 
>> signature, place the rest at the centre of the remaining blank space.
>> 
>> 
>> \version "2.20.0"
>> {
>>  \new StaffGroup
>>  <<
>>\new Dynamics { s1-great s1-no s1-great s1-great }
>>\new Staff  \relative c'' { \clef bass R1 \clef treble | g4 f e d \clef 
>> bass | c,,1 | R1 | }
>>\new Staff  \relative c'' { R1 | R1 | R1 \clef bass | R1 | }
>>>> 
>> }
>> 
>> I am correcting this with:
>>\once \override score.MultiMeasureRest.X-offset = 1.5 %but ofcourse 
>> varies
>> 
>> Many thanks,
>> 
>> Owain Evans
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> 
> Hi Owain,
> 
> per default left/right spacing of a MultiMeasureRest (MMR) is done
> according to left/right break-alignment (a clef change belongs to it).
> This is done score-wide, thus the spacing of MMRs is equal for all of
> them even if only in one Staff a clef change happens.
> 
> You can affect this by overriding the spacing-pair-property:
> 
> work-around =
> \once \override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)
> 
> {
>  \new StaffGroup
>  <<
>\new Dynamics { s1-great s1-fixed s1-great s1-great }
>\new Staff
>  \relative c'' {
>\clef bass R1 \clef treble | g4 f e d \clef bass | c,,1 | R1 |
>  }
>\new Staff
>  \relative c'' { R1 | \work-around R1 | R1 \clef bass | R1 | }
>>> 
> }
> 
> Alas, I'm undecided whether it's a bug or not, look at the output of:
> 
> <<
>  \new Staff { R1 R \clef bass R }
>  \new Staff { R1 \work-around R R }
>>> 
> 
> The MMRs don't line up, no surprise. Though, I seem to remember some
> users prefer this, but other users want the MMRs to be aligned.
> And we have the demonstrated and documented override to fulfill both wishes.
> Admittedly the documentation is poor and hard to find, perhaps we
> should created a snippet in NR or at least i Documentation/snippets
> 
> Cheers,
>  Harm

Hi Harm,

I appreciate your time on this.
Your solution with a constant variable is the way.
I would put `Score` in the work-around, i.e.:

work-around =
\once \override Score.MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)

as the two rests are not vertically aligned otherwise.

I would always centre these rests and ignore the space created by the clef (my 
first example of “great” I’d now say “no”).
It’s much more noticeable on shorter measure lengths i.e. 2/4 vs 4/4

I think it is best not left as a bug, but this left in the searchable archive. 
It’s more flexible and less opinionated. And especially that there are already 
different opinions.

My reasoning is looking through scores, they are not consistent at all. I even 
found a 1930s Durant edition convention on irregular time signatures of 7/4 
where the rest placement is deliberately off centre (unless a typo error).

But please understand my logic for a staff event (clef change) to affect a 
score event (MMR) of perhaps multiple staffs, just seems up-side-down.

but sincere thanks,

Owain




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[Thomas Morley]

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 in this case.
> I.e. The rest's centring between the two barlines presides over the addition 
> of the clef symbol.
>
> Gould p. 160: says "When the rest bar contains a clef, key signature or time 
> signature, place the rest at the centre of the remaining blank space.
>
>
> \version "2.20.0"
> {
>   \new StaffGroup
>   <<
> \new Dynamics { s1-great s1-no s1-great s1-great }
> \new Staff  \relative c'' { \clef bass R1 \clef treble | g4 f e d \clef 
> bass | c,,1 | R1 | }
> \new Staff  \relative c'' { R1 | R1 | R1 \clef bass | R1 | }
>   >>
> }
>
> I am correcting this with:
> \once \override score.MultiMeasureRest.X-offset = 1.5 %but ofcourse 
> varies
>
> Many thanks,
>
> Owain Evans
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Owain,

per default left/right spacing of a MultiMeasureRest (MMR) is done
according to left/right break-alignment (a clef change belongs to it).
This is done score-wide, thus the spacing of MMRs is equal for all of
them even if only in one Staff a clef change happens.

You can affect this by overriding the spacing-pair-property:

work-around =
\once \override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)

{
  \new StaffGroup
  <<
\new Dynamics { s1-great s1-fixed s1-great s1-great }
\new Staff
  \relative c'' {
\clef bass R1 \clef treble | g4 f e d \clef bass | c,,1 | R1 |
  }
\new Staff
  \relative c'' { R1 | \work-around R1 | R1 \clef bass | R1 | }
  >>
}

Alas, I'm undecided whether it's a bug or not, look at the output of:

<<
  \new Staff { R1 R \clef bass R }
  \new Staff { R1 \work-around R R }
>>

The MMRs don't line up, no surprise. Though, I seem to remember some
users prefer this, but other users want the MMRs to be aligned.
And we have the demonstrated and documented override to fulfill both wishes.
Admittedly the documentation is poor and hard to find, perhaps we
should created a snippet in NR or at least i Documentation/snippets

Cheers,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Undesired MultiMeasureRest X position when clef change at end of measure

[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 in this case. 
I.e. The rest's centring between the two barlines presides over the addition of 
the clef symbol. 

Gould p. 160: says "When the rest bar contains a clef, key signature or time 
signature, place the rest at the centre of the remaining blank space.


\version "2.20.0"
{
  \new StaffGroup
  <<
\new Dynamics { s1-great s1-no s1-great s1-great }
\new Staff  \relative c'' { \clef bass R1 \clef treble | g4 f e d \clef 
bass | c,,1 | R1 | }
\new Staff  \relative c'' { R1 | R1 | R1 \clef bass | R1 | }
  >>
}

I am correcting this with:
\once \override score.MultiMeasureRest.X-offset = 1.5 %but ofcourse 
varies 

Many thanks,

Owain Evans
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Clef change and repeat sign

[Pierre Perol-Schneider]

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@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[foxfanfare]

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 
> time signature, one has to center the rest in the remaining space”, see 
> attachment.
> 
> So Gould is inconsistent here ;)

Yes I see :) Well it's p.160 in the english version. In my opinion, this
rule only applies when you write with a single staff, that's all. I
understand why LP has been configured that way and your right, it's not a
bug. But I'll have to remember correcting that each time I write for several
musicians or at least with 2-staves instruments!

It seems to me to be an engraving issue, especially when you write
orchestral music. Don't you think it would be a good idea to put the
demonstration with \override MultiMeasureRest.spacing-pair = #'(staff-bar .
staff-bar) in the documentation after
http://lilypond.org/doc/v2.19/Documentation/notation/writing-rests#full-measure-rests
 
?





--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Malte Meyn]

Am 27.10.19 um 17:30 schrieb foxfanfare:

Thanks for your replies. Where did you find this reference in Gould's book?
I was looking for that before writing my initial post but without success.
On the contrary, I found this example which suggests otherwise (see the
second one):
mmr.jpg<http://lilypond.1069038.n5.nabble.com/file/t5604/mmr.jpg>   


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 
time signature, one has to center the rest in the remaining space”, see 
attachment.


So Gould is inconsistent here ;)


I also rember writing orchestral music and I found always strange when
several MMR where not centered in their measure because only one instrument
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

[foxfanfare]

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.
> 
> According to Gould LilyPond’s behaviour is correct, but she doesn’t say 
> anything about full scores …

Thanks for your replies. Where did you find this reference in Gould's book?
I was looking for that before writing my initial post but without success.
On the contrary, I found this example which suggests otherwise (see the
second one):
mmr.jpg <http://lilypond.1069038.n5.nabble.com/file/t5604/mmr.jpg>  

I also rember writing orchestral music and I found always strange when
several MMR where not centered in their measure because only one instrument
had a clef change... Or maybe I don't get your point.


Thomas Morley-2 wrote
> Nevertheless you can change this behaviour by applying
> [\once]
> \override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)
> as stated in the IR.

That's good to know, thank you very much.



--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Thomas Morley]

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 "2.19.82"
>
> \new Staff
> \relative c' {
>   c1
>   R-"default"
>   \bar "||"
>   R_"not centered"
>   \clef bass
>   \once \override MultiMeasureRest.X-offset = #1
>   R-"tweaked"
>   \clef treble
>   c
> }
>
> What do you think?
>
> clefchange.ly
> <http://lilypond.1069038.n5.nabble.com/file/t5604/clefchange.ly>
> clefchange.pdf
> <http://lilypond.1069038.n5.nabble.com/file/t5604/clefchange.pdf>

Well, while centering a MMR the question is "center between which items?"
Default LilyPond centers between left and right break-alignment.
That's what's done and what you see.
So no bug, but intended.

Nevertheless you can change this behaviour by applying
[\once]
\override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)
as stated in the IR.


Cheers,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change and measure length

[Malte Meyn]

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
   R-"default"
   \bar "||"
   R_"not centered"
   \clef bass
   \once \override MultiMeasureRest.X-offset = #1
   R-"tweaked"
   \clef treble
   c
}

What do you think?


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.


According to Gould LilyPond’s behaviour is correct, but she doesn’t say 
anything about full scores …


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Clef change and measure length

[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
  R-"default"
  \bar "||"
  R_"not centered"
  \clef bass
  \once \override MultiMeasureRest.X-offset = #1
  R-"tweaked"
  \clef treble
  c
}

What do you think?

clefchange.ly
<http://lilypond.1069038.n5.nabble.com/file/t5604/clefchange.ly>  
clefchange.pdf
<http://lilypond.1069038.n5.nabble.com/file/t5604/clefchange.pdf>  




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Thomas Morley]

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 columns.
(Spacers don't cause a NoteColumn)

Look at the example below:

  \new PianoStaff <<
  \new Staff = "RH" {
  a'8 a' a' a'
  a'
  \change Staff = "LH"
  \clef treble
  ais'
  \change Staff = "RH"
  a'4

  }
  \new Staff = "LH" {
  c'8 s4.
  \mark \default
  \clef bass
  c'8
  s8
  \mark \default
  \clef bass
  c4
  }
  >>

At "A" we don't want additional spacing as opposed to "B"
Though, this is user-settable, albeit not documented.

  \new PianoStaff <<
  \new Staff = "RH" {
  a'8 a' a' a'
  a'
  \change Staff = "LH"
  \clef treble
  ais'
  \change Staff = "RH"
  a'4

  }
  \new Staff = "LH" {
  c'8 s4.
  \mark \default
  \clef bass
  c'8
  \override Score.NonMusicalPaperColumn.allow-loose-spacing = ##f
  s8
  \revert Score.NonMusicalPaperColumn.allow-loose-spacing
  \mark \default
  \clef bass
  c4
  }
  >>

So we have at least a documentation-issue, imho.

Cheers,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[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

On Mon, Oct 9, 2017 at 4:09 AM, Malte Meyn <lilyp...@maltemeyn.de> wrote:

> Hi Ophir,
>
> this bug hasn’t been fixed yet but there’s a cleaner solution than
> tweaking X-offsets and X-extents: Temporarily use another voice.
>
> Cheers,
> Malte
>
> \version "2.18.2"
>
> \new PianoStaff <<
>   \new Staff = "RH" \relative a' {
> \clef treble
> <<
>   \new Voice {
> s2
> a8[ b c d]
>   }
>   \new Voice {
> a8
> \change Staff = "LH" \clef treble a_1
> \change Staff = "RH"  a
> \change Staff = "LH"  a_2
> \clef bass
> cis,, d e f
>   }
> >>
> e''2
>   }
>   \new Staff = "LH" \relative a, {
> \clef bass
> a8 s2..
> e'2
>
>   }
> >>
>
> Am 09.10.2017 um 05:23 schrieb Ophir Lifshitz:
>
>> Hello,
>>
>> Can someone please triage this bug?
>>
>> Thanks again,
>> Ophir
>>
>> On Sun, Jan 31, 2016 at 4:57 PM, Ophir Lifshitz <
>> hangfromthefl...@gmail.com>
>> wrote:
>>
>> Hello,
>>>
>>> Would it be possible to triage this bug I reported 3 months ago?
>>>
>>> Thanks,
>>> Ophir
>>>
>>> On Fri, Jan 1, 2016 at 10:03 AM, Ophir Lifshitz <
>>> hangfromthefl...@gmail.com> wrote:
>>>
>>> Hello again,
>>>>
>>>> Has anyone been able to triage this bug yet?
>>>>
>>>> Thanks,
>>>> Ophir
>>>>
>>>> On Wed, Oct 28, 2015 at 11:31 AM, Ophir Lifshitz <
>>>> hangfromthefl...@gmail.com> wrote:
>>>>
>>>> I was browsing through recent bugs on the new tracker and found this
>>>>> one: http://sourceforge.net/p/testlilyissues/issues/4642/
>>>>>
>>>>> I wonder whether it is related?
>>>>>
>>>>> Ophir
>>>>>
>>>>> 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.
>>>>>>
>>>>>> Ophir
>>>>>>
>>>>>> 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 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's note's presence in the 4th position of the LH
>>>>>>> staff,
>>>>>>> and it only detects the presence of a LH note/rest starting
>>>>>>> somewhere in
>>>>>>> the 4th position.
>>>>>>>
>>>>>>> Ophir
>>>>>>>
>>>>>>> On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
>>>>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>>>>
>>>>>>> Oops, sorry, too fast reading...
>>>>>>>>
>>>>>>>> How about :
>>>>>>>>
>>>>>>>> \version "2.19.22"
>>>>>>>> \new PianoStaff <<
>>>>>>>>  \new Staff = "RH" \relative a' {
>>>>>>>>  \clef treble
>>>>>>>>  a8
>>>>>>>>  \change Staff = "LH" \clef treble a_1
>>>>>>>>  \change Staff = "RH"  a
>>>>>>>>  \change Staff = "LH"
>>>>>>>>  \tweak X-extent #'(0 . -2)
>>>>>>>>  \tweak X-offset #-3.3 a_2
>>>>&

Re: Bad clef change collision when alternating piano staves

[Malte Meyn]

Hi Ophir,

this bug hasn’t been fixed yet but there’s a cleaner solution than 
tweaking X-offsets and X-extents: Temporarily use another voice.


Cheers,
Malte

\version "2.18.2"

\new PianoStaff <<
  \new Staff = "RH" \relative a' {
\clef treble
<<
  \new Voice {
s2
a8[ b c d]
  }
  \new Voice {
a8
\change Staff = "LH" \clef treble a_1
\change Staff = "RH"  a
\change Staff = "LH"  a_2
\clef bass
cis,, d e f
  }
>>
e''2
  }
  \new Staff = "LH" \relative a, {
\clef bass
a8 s2..
e'2
  }
>>

Am 09.10.2017 um 05:23 schrieb Ophir Lifshitz:

Hello,

Can someone please triage this bug?

Thanks again,
Ophir

On Sun, Jan 31, 2016 at 4:57 PM, Ophir Lifshitz <hangfromthefl...@gmail.com>
wrote:


Hello,

Would it be possible to triage this bug I reported 3 months ago?

Thanks,
Ophir

On Fri, Jan 1, 2016 at 10:03 AM, Ophir Lifshitz <
hangfromthefl...@gmail.com> wrote:


Hello again,

Has anyone been able to triage this bug yet?

Thanks,
Ophir

On Wed, Oct 28, 2015 at 11:31 AM, Ophir Lifshitz <
hangfromthefl...@gmail.com> wrote:


I was browsing through recent bugs on the new tracker and found this
one: http://sourceforge.net/p/testlilyissues/issues/4642/

I wonder whether it is related?

Ophir

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.

Ophir

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 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's note's presence in the 4th position of the LH staff,
and it only detects the presence of a LH note/rest starting somewhere in
the 4th position.

Ophir

On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:


Oops, sorry, too fast reading...

How about :

\version "2.19.22"
\new PianoStaff <<
 \new Staff = "RH" \relative a' {
 \clef treble
 a8
 \change Staff = "LH" \clef treble a_1
 \change Staff = "RH"  a
 \change Staff = "LH"
 \tweak X-extent #'(0 . -2)
 \tweak X-offset #-3.3 a_2
 \clef bass
 \change Staff = "RH"
 \tweak X-extent #'(-7 . 1.3) a
 }
 \new Staff = "LH" \relative a, {
 \clef bass
 a8 s4. cis8_3
 }






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 sharped note 3, and not in the small space
between notes 1 and 2. Shifting it left makes it look like note 2 is
notated in bass clef, but it is not. Ultimately more space is needed on the
staff between notes 2 and 3 to fit the bass clef before note 3.

Ophir

On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:


Hi Ophir,

Try :
\once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass

Cheers,
~Pierre

2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <
hangfromthefl...@gmail.com>:


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 slightly before note 2. I would have instead
expected
to see a lot of space made between notes 2 and 3 where the clef
can fit
properly. The clef change before note 1 shows that Lilypond can
indeed make
space for clef changes.

If not a bug, what is the best way to fix the collision?

Thanks in advance,
Ophir

P.S. The MWE was gradually simplified (1 <
http://lilybin.com/gs2oks/1> 2
<http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
<http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>)
in
case anyone is curious for the source
<https://www.youtube.com/watch?v=3Dw1Huh_Tfg=
youtu.be=2m51s>.
Also attached are the source and an image in case of linkrot.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond



















___

Re: Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

Hello,

Can someone please triage this bug?

Thanks again,
Ophir

On Sun, Jan 31, 2016 at 4:57 PM, Ophir Lifshitz <hangfromthefl...@gmail.com>
wrote:

> Hello,
>
> Would it be possible to triage this bug I reported 3 months ago?
>
> Thanks,
> Ophir
>
> On Fri, Jan 1, 2016 at 10:03 AM, Ophir Lifshitz <
> hangfromthefl...@gmail.com> wrote:
>
>> Hello again,
>>
>> Has anyone been able to triage this bug yet?
>>
>> Thanks,
>> Ophir
>>
>> On Wed, Oct 28, 2015 at 11:31 AM, Ophir Lifshitz <
>> hangfromthefl...@gmail.com> wrote:
>>
>>> I was browsing through recent bugs on the new tracker and found this
>>> one: http://sourceforge.net/p/testlilyissues/issues/4642/
>>>
>>> I wonder whether it is related?
>>>
>>> Ophir
>>>
>>> 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.
>>>>
>>>> Ophir
>>>>
>>>> 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 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's note's presence in the 4th position of the LH staff,
>>>>> and it only detects the presence of a LH note/rest starting somewhere in
>>>>> the 4th position.
>>>>>
>>>>> Ophir
>>>>>
>>>>> On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
>>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>>
>>>>>> Oops, sorry, too fast reading...
>>>>>>
>>>>>> How about :
>>>>>>
>>>>>> \version "2.19.22"
>>>>>> \new PianoStaff <<
>>>>>> \new Staff = "RH" \relative a' {
>>>>>> \clef treble
>>>>>>     a8
>>>>>> \change Staff = "LH" \clef treble a_1
>>>>>> \change Staff = "RH"  a
>>>>>> \change Staff = "LH"
>>>>>> \tweak X-extent #'(0 . -2)
>>>>>> \tweak X-offset #-3.3 a_2
>>>>>> \clef bass
>>>>>> \change Staff = "RH"
>>>>>> \tweak X-extent #'(-7 . 1.3) a
>>>>>> }
>>>>>> \new Staff = "LH" \relative a, {
>>>>>> \clef bass
>>>>>> a8 s4. cis8_3
>>>>>> }
>>>>>> >>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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 sharped note 3, and not in the small 
>>>>>>> space
>>>>>>> between notes 1 and 2. Shifting it left makes it look like note 2 is
>>>>>>> notated in bass clef, but it is not. Ultimately more space is needed on 
>>>>>>> the
>>>>>>> staff between notes 2 and 3 to fit the bass clef before note 3.
>>>>>>>
>>>>>>> Ophir
>>>>>>>
>>>>>>> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
>>>>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Ophir,
>>>>>>>>
>>>>>>>> Try :
>>>>>>>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>>>>>>>

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

[Simon Albrecht]

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 comes the code %%


there won’t be any interferences with Markdown syntax. (TeX is just a 
replacement, since there is no LilyPond syntax highlighting available).
Also it would be nice to use standard code formatting (indenting, line 
breaks) for general legibility.


Best, Simon

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[Simon Albrecht]

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 be 
more descriptive.


Best, Simon

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[Javier Ruiz-Alma]

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://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[David Kastrup]

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 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''4\( c''  \break
>>  c''1\)
>>  c''4 c'' c'' c''(  \break
>>  c''1)
>>}
>>{ c''1 \clef bass
>>  c'  c' \clef treble
>>  c'
>>}
>>   >>
>>   \layout { ragged-right = ##t indent = 0 }
>> }
>>
>
> The problem you're seeing is that the right-bound of the slur is set
> to the *left* extent of the NonMusicalPaperColumn that encompasses the
> end materials of the line: Ordinarily, this means that a slur will end
> slightly before a barline, which looks fine.  Unfortunately, the
> cautionary clef belongs to the NonMusicalPaperColumn at the end of the
> line, hence the distortion you're seeing.
>
> (The endpoint seems to be created in
> Slur_score_state::get_base_attachments in lily/slur-scoring.cc.)
>
> What's needed is the ability to align the endpoint of a slur to
> specific elements within the 'elements array of the paper column
> bound.  Something like the 'break-alignable-interface which allows
> flexible alignments to grobs like BarNumber.

Would the behavior be correct if the clef/key change happened in the
system of the slur itself?  Or should we just aim for the right end of
the NonMusicalPaperColumn minus an offset?

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[Thomas Morley]

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 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''4\( c''  \break
>>  c''1\)
>>  c''4 c'' c'' c''(  \break
>>  c''1)
>>}
>>{ c''1 \clef bass
>>  c'  c' \clef treble
>>  c'
>>}
>>   >>
>>   \layout { ragged-right = ##t indent = 0 }
>> }
>>
>
> The problem you're seeing is that the right-bound of the slur is set
> to the *left* extent of the NonMusicalPaperColumn that encompasses the
> end materials of the line: Ordinarily, this means that a slur will end
> slightly before a barline, which looks fine.  Unfortunately, the
> cautionary clef belongs to the NonMusicalPaperColumn at the end of the
> line, hence the distortion you're seeing.
>
> (The endpoint seems to be created in
> Slur_score_state::get_base_attachments in lily/slur-scoring.cc.)
>
> What's needed is the ability to align the endpoint of a slur to
> specific elements within the 'elements array of the paper column
> bound.  Something like the 'break-alignable-interface which allows
> flexible alignments to grobs like BarNumber.
>
> David



Hi David,

thanks for your analysis, which reminded me, how I dealed with the
problem in the bend-engraver.
There I mimiced the default behaviour, but you can do it different, at
least manually. (Although reading a property is surely the way to go.)

As a proof of concept, setting all but last broken curve's right-bound
to BarLine:

\version "2.19.48"

#(define (set-broken-curve-right-bound grob)
  (let* ((orig (ly:grob-original grob))
 (siblings (if (ly:grob? orig)
   (ly:spanner-broken-into orig)
   '(
(if (and (pair? siblings) (not (equal? grob (last siblings
(let* ((right-bound
 (ly:spanner-bound grob RIGHT))
   (right-bound-elts
   (ly:grob-array->list (ly:grob-object right-bound 'elements)))
   (bar-lines
 (filter
   (lambda (g) (grob::has-interface g 'bar-line-interface))
   right-bound-elts)))
  (if (pair? bar-lines)
  (ly:spanner-set-bound! grob RIGHT (car bar-lines)))

resetRightBound = {
  \override Slur.after-line-breaking = #set-broken-curve-right-bound
  \override PhrasingSlur.after-line-breaking = #set-broken-curve-right-bound
}

\score {
  <<
   { c''2 \resetRightBound c''4\( c''  \break
 c''1\)
 c''4 c'' c'' c''(\break
 c''1)
   }
   { c''1 \clef bass
 c'  c' \clef treble
 c'
   }
  >>
  \layout { ragged-right = ##t indent = 0 }
}

Cheers,
  Harm

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[Javier Ruiz-Alma]

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''4\( c''  \break 
 c''1\) 
 c''4 c'' c'' c''(  \break 
 c''1) 
   } 
   { c''1 \clef bass 
 c'  c' \clef treble 
 c' 
   } 
  >> 
  \layout { ragged-right = ##t indent = 0 } 
}

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

Hello,

Would it be possible to triage this bug I reported 3 months ago?

Thanks,
Ophir

On Fri, Jan 1, 2016 at 10:03 AM, Ophir Lifshitz <hangfromthefl...@gmail.com>
wrote:

> Hello again,
>
> Has anyone been able to triage this bug yet?
>
> Thanks,
> Ophir
>
> On Wed, Oct 28, 2015 at 11:31 AM, Ophir Lifshitz <
> hangfromthefl...@gmail.com> wrote:
>
>> I was browsing through recent bugs on the new tracker and found this one:
>> http://sourceforge.net/p/testlilyissues/issues/4642/
>>
>> I wonder whether it is related?
>>
>> Ophir
>>
>> 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.
>>>
>>> Ophir
>>>
>>> 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 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's note's presence in the 4th position of the LH staff,
>>>> and it only detects the presence of a LH note/rest starting somewhere in
>>>> the 4th position.
>>>>
>>>> Ophir
>>>>
>>>> On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>
>>>>> Oops, sorry, too fast reading...
>>>>>
>>>>> How about :
>>>>>
>>>>> \version "2.19.22"
>>>>> \new PianoStaff <<
>>>>> \new Staff = "RH" \relative a' {
>>>>> \clef treble
>>>>> a8
>>>>> \change Staff = "LH" \clef treble a_1
>>>>> \change Staff = "RH"  a
>>>>> \change Staff = "LH"
>>>>> \tweak X-extent #'(0 . -2)
>>>>> \tweak X-offset #-3.3 a_2
>>>>> \clef bass
>>>>> \change Staff = "RH"
>>>>> \tweak X-extent #'(-7 . 1.3) a
>>>>> }
>>>>> \new Staff = "LH" \relative a, {
>>>>> \clef bass
>>>>> a8 s4. cis8_3
>>>>> }
>>>>> >>
>>>>>
>>>>>
>>>>>
>>>>> 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 sharped note 3, and not in the small space
>>>>>> between notes 1 and 2. Shifting it left makes it look like note 2 is
>>>>>> notated in bass clef, but it is not. Ultimately more space is needed on 
>>>>>> the
>>>>>> staff between notes 2 and 3 to fit the bass clef before note 3.
>>>>>>
>>>>>> Ophir
>>>>>>
>>>>>> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
>>>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Ophir,
>>>>>>>
>>>>>>> Try :
>>>>>>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>>>>>>
>>>>>>> Cheers,
>>>>>>> ~Pierre
>>>>>>>
>>>>>>> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <
>>>>>>> hangfromthefl...@gmail.com>:
>>>>>>>
>>>>>>>> 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 slightly before note 2. I would have instead
>>>>>>>> expected
>>>>>>>> to see a lot of space made between notes 2 and 3 where the clef can
>>>>>>>> fit
>>>>>>>> properly. The clef change before note 1 shows that Lilypond can
>>>>>>>> indeed make
>>>>>>>> space for clef changes.
>>>>>>>>
>>>>>>>> If not a bug, what is the best way to fix the collision?
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>> Ophir
>>>>>>>>
>>>>>>>> P.S. The MWE was gradually simplified (1 <
>>>>>>>> http://lilybin.com/gs2oks/1> 2
>>>>>>>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>>>>>>>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>)
>>>>>>>> in
>>>>>>>> case anyone is curious for the source
>>>>>>>> <
>>>>>>>> https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s
>>>>>>>> >.
>>>>>>>> Also attached are the source and an image in case of linkrot.
>>>>>>>>
>>>>>>>> ___
>>>>>>>> bug-lilypond mailing list
>>>>>>>> bug-lilypond@gnu.org
>>>>>>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

Hello again,

Has anyone been able to triage this bug yet?

Thanks,
Ophir

On Wed, Oct 28, 2015 at 11:31 AM, Ophir Lifshitz <hangfromthefl...@gmail.com
> wrote:

> I was browsing through recent bugs on the new tracker and found this one:
> http://sourceforge.net/p/testlilyissues/issues/4642/
>
> I wonder whether it is related?
>
> Ophir
>
> 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.
>>
>> Ophir
>>
>> 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 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's note's presence in the 4th position of the LH staff,
>>> and it only detects the presence of a LH note/rest starting somewhere in
>>> the 4th position.
>>>
>>> Ophir
>>>
>>> On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
>>> pierre.schneider.pa...@gmail.com> wrote:
>>>
>>>> Oops, sorry, too fast reading...
>>>>
>>>> How about :
>>>>
>>>> \version "2.19.22"
>>>> \new PianoStaff <<
>>>> \new Staff = "RH" \relative a' {
>>>> \clef treble
>>>> a8
>>>> \change Staff = "LH" \clef treble a_1
>>>> \change Staff = "RH"  a
>>>> \change Staff = "LH"
>>>> \tweak X-extent #'(0 . -2)
>>>> \tweak X-offset #-3.3 a_2
>>>> \clef bass
>>>> \change Staff = "RH"
>>>> \tweak X-extent #'(-7 . 1.3) a
>>>> }
>>>> \new Staff = "LH" \relative a, {
>>>> \clef bass
>>>> a8 s4. cis8_3
>>>> }
>>>> >>
>>>>
>>>>
>>>>
>>>> 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 sharped note 3, and not in the small space
>>>>> between notes 1 and 2. Shifting it left makes it look like note 2 is
>>>>> notated in bass clef, but it is not. Ultimately more space is needed on 
>>>>> the
>>>>> staff between notes 2 and 3 to fit the bass clef before note 3.
>>>>>
>>>>> Ophir
>>>>>
>>>>> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
>>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>>
>>>>>> Hi Ophir,
>>>>>>
>>>>>> Try :
>>>>>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>>>>>
>>>>>> Cheers,
>>>>>> ~Pierre
>>>>>>
>>>>>> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com
>>>>>> >:
>>>>>>
>>>>>>> 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 slightly before note 2. I would have instead
>>>>>>> expected
>>>>>>> to see a lot of space made between notes 2 and 3 where the clef can
>>>>>>> fit
>>>>>>> properly. The clef change before note 1 shows that Lilypond can
>>>>>>> indeed make
>>>>>>> space for clef changes.
>>>>>>>
>>>>>>> If not a bug, what is the best way to fix the collision?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Ophir
>>>>>>>
>>>>>>> P.S. The MWE was gradually simplified (1 <
>>>>>>> http://lilybin.com/gs2oks/1> 2
>>>>>>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>>>>>>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>)
>>>>>>> in
>>>>>>> case anyone is curious for the source
>>>>>>> <
>>>>>>> https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s
>>>>>>> >.
>>>>>>> Also attached are the source and an image in case of linkrot.
>>>>>>>
>>>>>>> ___
>>>>>>> bug-lilypond mailing list
>>>>>>> bug-lilypond@gnu.org
>>>>>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

I was browsing through recent bugs on the new tracker and found this one:
http://sourceforge.net/p/testlilyissues/issues/4642/

I wonder whether it is related?

Ophir

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.
>
> Ophir
>
> 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 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's note's presence in the 4th position of the LH staff, and it
>> only detects the presence of a LH note/rest starting somewhere in the 4th
>> position.
>>
>> Ophir
>>
>> On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
>> pierre.schneider.pa...@gmail.com> wrote:
>>
>>> Oops, sorry, too fast reading...
>>>
>>> How about :
>>>
>>> \version "2.19.22"
>>> \new PianoStaff <<
>>> \new Staff = "RH" \relative a' {
>>> \clef treble
>>> a8
>>> \change Staff = "LH" \clef treble a_1
>>> \change Staff = "RH"  a
>>> \change Staff = "LH"
>>> \tweak X-extent #'(0 . -2)
>>> \tweak X-offset #-3.3 a_2
>>> \clef bass
>>> \change Staff = "RH"
>>> \tweak X-extent #'(-7 . 1.3) a
>>> }
>>> \new Staff = "LH" \relative a, {
>>> \clef bass
>>> a8 s4. cis8_3
>>> }
>>> >>
>>>
>>>
>>>
>>> 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 sharped note 3, and not in the small space
>>>> between notes 1 and 2. Shifting it left makes it look like note 2 is
>>>> notated in bass clef, but it is not. Ultimately more space is needed on the
>>>> staff between notes 2 and 3 to fit the bass clef before note 3.
>>>>
>>>> Ophir
>>>>
>>>> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
>>>> pierre.schneider.pa...@gmail.com> wrote:
>>>>
>>>>> Hi Ophir,
>>>>>
>>>>> Try :
>>>>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>>>>
>>>>> Cheers,
>>>>> ~Pierre
>>>>>
>>>>> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>
>>>>> :
>>>>>
>>>>>> 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 slightly before note 2. I would have instead
>>>>>> expected
>>>>>> to see a lot of space made between notes 2 and 3 where the clef can
>>>>>> fit
>>>>>> properly. The clef change before note 1 shows that Lilypond can
>>>>>> indeed make
>>>>>> space for clef changes.
>>>>>>
>>>>>> If not a bug, what is the best way to fix the collision?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Ophir
>>>>>>
>>>>>> P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1>
>>>>>> 2
>>>>>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>>>>>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>)
>>>>>> in
>>>>>> case anyone is curious for the source
>>>>>> <https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s
>>>>>> >.
>>>>>> Also attached are the source and an image in case of linkrot.
>>>>>>
>>>>>> ___
>>>>>> bug-lilypond mailing list
>>>>>> bug-lilypond@gnu.org
>>>>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Pierre Perol-Schneider]

Oops, sorry, too fast reading...

How about :

\version "2.19.22"
\new PianoStaff <<
\new Staff = "RH" \relative a' {
\clef treble
a8
\change Staff = "LH" \clef treble a_1
\change Staff = "RH"  a
\change Staff = "LH"
\tweak X-extent #'(0 . -2)
\tweak X-offset #-3.3 a_2
\clef bass
\change Staff = "RH"
\tweak X-extent #'(-7 . 1.3) a
}
\new Staff = "LH" \relative a, {
\clef bass
a8 s4. cis8_3
}
>>



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 sharped note 3, and not in the small space between
> notes 1 and 2. Shifting it left makes it look like note 2 is notated in
> bass clef, but it is not. Ultimately more space is needed on the staff
> between notes 2 and 3 to fit the bass clef before note 3.
>
> Ophir
>
> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
> pierre.schneider.pa...@gmail.com> wrote:
>
>> Hi Ophir,
>>
>> Try :
>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>
>> Cheers,
>> ~Pierre
>>
>> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>:
>>
>>> 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 slightly before note 2. I would have instead
>>> expected
>>> to see a lot of space made between notes 2 and 3 where the clef can fit
>>> properly. The clef change before note 1 shows that Lilypond can indeed
>>> make
>>> space for clef changes.
>>>
>>> If not a bug, what is the best way to fix the collision?
>>>
>>> Thanks in advance,
>>> Ophir
>>>
>>> P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1> 2
>>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>) in
>>> case anyone is curious for the source
>>> <https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s>.
>>> Also attached are the source and an image in case of linkrot.
>>>
>>> ___
>>> bug-lilypond mailing list
>>> bug-lilypond@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>>
>>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

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 slightly before note 2. I would have instead expected
to see a lot of space made between notes 2 and 3 where the clef can fit
properly. The clef change before note 1 shows that Lilypond can indeed make
space for clef changes.

If not a bug, what is the best way to fix the collision?

Thanks in advance,
Ophir

P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1> 2
<http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
<http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>) in
case anyone is curious for the source
<https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s>.
Also attached are the source and an image in case of linkrot.


clef-collision.ly
Description: Binary data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Pierre Perol-Schneider]

Hi Ophir,

Try :
\once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass

Cheers,
~Pierre

2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>:

> 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 slightly before note 2. I would have instead expected
> to see a lot of space made between notes 2 and 3 where the clef can fit
> properly. The clef change before note 1 shows that Lilypond can indeed make
> space for clef changes.
>
> If not a bug, what is the best way to fix the collision?
>
> Thanks in advance,
> Ophir
>
> P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1> 2
> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>) in
> case anyone is curious for the source
> <https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s>.
> Also attached are the source and an image in case of linkrot.
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

And so in that case, probably something like \hideNotes r ... \unHideNotes
will be sufficient.

Ophir

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 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's note's presence in the 4th position of the LH staff, and it
> only detects the presence of a LH note/rest starting somewhere in the 4th
> position.
>
> Ophir
>
> On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
> pierre.schneider.pa...@gmail.com> wrote:
>
>> Oops, sorry, too fast reading...
>>
>> How about :
>>
>> \version "2.19.22"
>> \new PianoStaff <<
>> \new Staff = "RH" \relative a' {
>> \clef treble
>> a8
>> \change Staff = "LH" \clef treble a_1
>> \change Staff = "RH"  a
>> \change Staff = "LH"
>> \tweak X-extent #'(0 . -2)
>> \tweak X-offset #-3.3 a_2
>> \clef bass
>> \change Staff = "RH"
>> \tweak X-extent #'(-7 . 1.3) a
>> }
>> \new Staff = "LH" \relative a, {
>> \clef bass
>>     a8 s4. cis8_3
>> }
>> >>
>>
>>
>>
>> 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 sharped note 3, and not in the small space between
>>> notes 1 and 2. Shifting it left makes it look like note 2 is notated in
>>> bass clef, but it is not. Ultimately more space is needed on the staff
>>> between notes 2 and 3 to fit the bass clef before note 3.
>>>
>>> Ophir
>>>
>>> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
>>> pierre.schneider.pa...@gmail.com> wrote:
>>>
>>>> Hi Ophir,
>>>>
>>>> Try :
>>>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>>>
>>>> Cheers,
>>>> ~Pierre
>>>>
>>>> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>:
>>>>
>>>>> 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 slightly before note 2. I would have instead
>>>>> expected
>>>>> to see a lot of space made between notes 2 and 3 where the clef can fit
>>>>> properly. The clef change before note 1 shows that Lilypond can indeed
>>>>> make
>>>>> space for clef changes.
>>>>>
>>>>> If not a bug, what is the best way to fix the collision?
>>>>>
>>>>> Thanks in advance,
>>>>> Ophir
>>>>>
>>>>> P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1>
>>>>> 2
>>>>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>>>>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>)
>>>>> in
>>>>> case anyone is curious for the source
>>>>> <https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s
>>>>> >.
>>>>> Also attached are the source and an image in case of linkrot.
>>>>>
>>>>> ___
>>>>> bug-lilypond mailing list
>>>>> bug-lilypond@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>>>>
>>>>>
>>>>
>>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[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 not in the small space between
notes 1 and 2. Shifting it left makes it look like note 2 is notated in
bass clef, but it is not. Ultimately more space is needed on the staff
between notes 2 and 3 to fit the bass clef before note 3.

Ophir

On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Hi Ophir,
>
> Try :
> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>
> Cheers,
> ~Pierre
>
> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>:
>
>> 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 slightly before note 2. I would have instead expected
>> to see a lot of space made between notes 2 and 3 where the clef can fit
>> properly. The clef change before note 1 shows that Lilypond can indeed
>> make
>> space for clef changes.
>>
>> If not a bug, what is the best way to fix the collision?
>>
>> Thanks in advance,
>> Ophir
>>
>> P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1> 2
>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>) in
>> case anyone is curious for the source
>> <https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s>.
>> Also attached are the source and an image in case of linkrot.
>>
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bad clef change collision when alternating piano staves

[Ophir Lifshitz]

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 plus a space r r s (collision). It seems that Lilypond can't detect
the RH's note's presence in the 4th position of the LH staff, and it only
detects the presence of a LH note/rest starting somewhere in the 4th
position.

Ophir

On Tue, Oct 27, 2015 at 6:01 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Oops, sorry, too fast reading...
>
> How about :
>
> \version "2.19.22"
> \new PianoStaff <<
> \new Staff = "RH" \relative a' {
> \clef treble
> a8
> \change Staff = "LH" \clef treble a_1
> \change Staff = "RH"  a
> \change Staff = "LH"
> \tweak X-extent #'(0 . -2)
> \tweak X-offset #-3.3 a_2
> \clef bass
> \change Staff = "RH"
> \tweak X-extent #'(-7 . 1.3) a
> }
> \new Staff = "LH" \relative a, {
> \clef bass
> a8 s4. cis8_3
> }
> >>
>
>
>
> 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 sharped note 3, and not in the small space between
>> notes 1 and 2. Shifting it left makes it look like note 2 is notated in
>> bass clef, but it is not. Ultimately more space is needed on the staff
>> between notes 2 and 3 to fit the bass clef before note 3.
>>
>> Ophir
>>
>> On Tue, Oct 27, 2015 at 5:28 PM, Pierre Perol-Schneider <
>> pierre.schneider.pa...@gmail.com> wrote:
>>
>>> Hi Ophir,
>>>
>>> Try :
>>> \once\override Staff.Clef.X-extent = #'(0 . 3.5) \clef bass
>>>
>>> Cheers,
>>> ~Pierre
>>>
>>> 2015-10-27 22:05 GMT+01:00 Ophir Lifshitz <hangfromthefl...@gmail.com>:
>>>
>>>> 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 slightly before note 2. I would have instead
>>>> expected
>>>> to see a lot of space made between notes 2 and 3 where the clef can fit
>>>> properly. The clef change before note 1 shows that Lilypond can indeed
>>>> make
>>>> space for clef changes.
>>>>
>>>> If not a bug, what is the best way to fix the collision?
>>>>
>>>> Thanks in advance,
>>>> Ophir
>>>>
>>>> P.S. The MWE was gradually simplified (1 <http://lilybin.com/gs2oks/1>
>>>> 2
>>>> <http://lilybin.com/gs2oks/2> 3 <http://lilybin.com/gs2oks/3> 4
>>>> <http://lilybin.com/gs2oks/4> current <http://lilybin.com/gs2oks/7>) in
>>>> case anyone is curious for the source
>>>> <https://www.youtube.com/watch?v=3Dw1Huh_Tfg=youtu.be=2m51s>.
>>>> Also attached are the source and an image in case of linkrot.
>>>>
>>>> ___
>>>> bug-lilypond mailing list
>>>> bug-lilypond@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>>>>
>>>>
>>>
>>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef change confuses manual key signature

[David Kastrup]

james james.lilyp...@googlemail.com writes:

 In the following:
 \version 2.14.2
 \score {
\relative c' {
   \time 2/4
   \set Staff.keySignature = #`(((0 . 4) . ,SHARP) ((0 . 3) . ,SHARP))
   \clef treble
   c8 a c d
 %%% 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
 around this?

Ok, consider me annoyed now.  Yes, we have some snippets documenting
this sort of thing, but what is it even supposed to mean?

The actual accidental _code_ knows two kinds of accidental entries: one
_without_ octave entry for the key signature, and one _with_ octave
entry _and_ bar/measure position for signifying a locally changed key
signature by a particular accidental in the music with given note and
octave and time.

The actual code does not try making sense of a _key_ signature entry
_with_ octave (and consequently without bar/measure position).  And what
is a key signature with octave location actually supposed to mean?  Do
we need an accidental for a note in key signature but one octave higher,
or not?

So I fail to make _any_ sense of your example.  If I had to guess, I'd
say the octave specifications are there for overriding the default
octaves chosen by the key signature engraver, but without 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 key signature down by entire octaves (thus keeping
the arrangement of the scale) until it starts making sense again?  Leave
it in the sky with ledger lines?  Without?

What is your expectation?  For what kind of music and situation is this
useful?

Without an answer to that question, I don't really know the direction
the fix should be taking properly.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

clef change confuses manual key signature

[james]

In the following:
\version 2.14.2
\score {
   \relative c' {
  \time 2/4
  \set Staff.keySignature = #`(((0 . 4) . ,SHARP) ((0 . 3) . ,SHARP))
  \clef treble
  c8 a c d
%%% 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 around this? 
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef change confuses manual key signature

[james]

On Aug 14, 2012, at 5:00 PM, David Kastrup wrote:

 james james.lilyp...@googlemail.com writes:
 
 So I fail to make _any_ sense of your example.  If I had to guess, I'd
 say the octave specifications are there for overriding the default
 octaves chosen by the key signature engraver, but without 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 key signature down by entire octaves (thus keeping
 the arrangement of the scale) until it starts making sense again?  Leave
 it in the sky with ledger lines?  Without?
 
 What is your expectation?  For what kind of music and situation is this
 useful?
 
 Without an answer to that question, I don't really know the direction
 the fix should be taking properly.

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:
\include deutsch.ly
\version 2.12.3
\score {
   
  \new Staff 
 \relative c'{
\time 1/4
\set Staff.keySignature = #`((9 . ,FLAT))
c4*1/3 d es f g a h a g f es d c4
 }
  
  \new Staff 
 \relative c' {
a4*1/3 h c d e fis gis fis e d c h a4
 }
 {  %% Key Signatures
\clef bass
\set Staff.keySignature = #`(((-1 . -3) . ,SHARP) ((-1 . -4) . 
,SHARP))
s4*2  | %1-18
\clef treble
\set Staff.printKeyCancellation = ##f
\set Staff.keySignature = #`(((0 . 4) . ,SHARP) ((0 . 3) . ,SHARP))
 }
  
   
   \layout {}
}
\score {
   
  \new Staff 
 \relative c'{
\time 1/4
\set Staff.keySignature = #`((9 . ,FLAT))
c4*1/3 d es f g a h a g f es d c4
 }
  
  \new Staff 
 \relative c' {
a4*1/3 h c d e fis gis fis e d c h a4
 }
 {  %% Key Signatures
\clef bass
\set Staff.keySignature = #`((4 . ,SHARP) (3 . ,SHARP))
s4*2  | %1-18
\clef treble
\set Staff.printKeyCancellation = ##f
\set Staff.keySignature = #`((4 . ,SHARP) (3 . ,SHARP))
 }
  
   
   \layout {}
}

I should note that making minor changes (like to the rhythm) may also solve the 
problem, but the important thing, for me at least, is that it shouldn't happen, 
regardless.


key signatures_2.12.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef change confuses manual key signature

[David Kastrup]

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 carry an accidental.
How do you distinguish a normal key signature (valid across all octaves)
from a restricted-octave one (valid only in one octave)?  They look the
same.

 I should note that making minor changes (like to the rhythm) may also
 solve the problem, but the important thing, for me at least, is that
 it shouldn't happen, regardless.

I can't make sense of your score, and I can't even make sense of your
sentences.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[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


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

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

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

[lilypond]

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
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 is  
wrongly positioned in that case. :)


It looks like a Break_align_engraver problem: despite the MetronomeMark  
being aligned on a note, it's still acknowledged as a break-alignable  
object.  It gets a BreakAlignment as a temporary X-parent (until the  
Metronome_engraver changes it at the end of the timestep), which interferes  
with the loose column the clef's attached to.


I think we can use 'non-musical to prevent this: if it's set in  
Metronome_engraver when we're sure the MetronomeMark *is* non-musical  
(i.e., not positioned over a note or rest), it should be easy to filter out  
any mark which doesn't need the services of the Break_align_engraver.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 bisect in the middle has a broken commit which  
doesn't compile. :(


there's probably some way to make git test a commit manually (so that I  
could avoid the broken-compile commit), but that range only has about 10  
commits in it, so at least I've reduced the range?




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change placed outside score

[Ralph Palmer]

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 not an error in 2.12.3.

 musx = \relative c'
 {
  % Change this to c4 for correct clef placement
  \times 2/3 {c8 c c}

  % Comment this out for correct clef placement
  \tempo asdf

  c4 c c
 }

 musy = \relative c'
 {
  \clef treble c4 \clef bass c4 c c
 }

 \score
 {
  
\new Staff \musx
\new Staff \musy
  
 }


Greetings, Jay Anderson and Lilyponders -

This has  been submitted as Issue 1695 :
http://code.google.com/p/lilypond/issues/detail?id=1695

Ralph
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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.


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Clef change placed outside score

[Jay Anderson]

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 Score.NonMusicalPaperColumn #'allow-loose-spacing = ##f
  c4
  \clef bass c4 c c
  \revert Score.NonMusicalPaperColumn #'allow-loose-spacing
}

This isn't the best as the clef now causes space to be made in the other staff.

The other workaround is just changing the tempo to a markup. I prefer
the tempo, but at least with this there isn't the extra space.

Are there other workarounds? Nothing else I tried seemed to work.

-Jay

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 (and in particular the fiddling with  
break-align-symbol(s) ) is the culprit. This would also fit the finding  
that replacing the \tempo call with a \mark or a \markup yields files that  
are okay. Only \tempo causes the problem (btw. the triplet is not  
necessary, it suffices to use two eighth notes. A quarter note fixes the  
problem, though, as observed in the original example).


Cheers,
Reinhold



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Clef change placed outside score

[Jay Anderson]

\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 clef placement
  \times 2/3 {c8 c c}

  % Comment this out for correct clef placement
  \tempo asdf

  c4 c c
}

musy = \relative c'
{
  \clef treble c4 \clef bass c4 c c
}

\score
{
  
\new Staff \musx
\new Staff \musy
  
}
attachment: error3.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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  
that we ask of patch submitters, so I can put it in the countdown, and the  
onus is on other people to say exactly what's wrong.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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
  git log -p -n 1 197e3ae339
or
  gitk 197e3ae339

I apologize for the convenience.

Graham, do you want to start a countdown, or should I just push it on my  
own when I think that people should have complained louder faster?



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 have complained louder faster.  But before  
it can get on a countdown, it needs to have a patch label.


I'll do another countdown tonight.


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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  
call_context_property_on_children () with the evaluated function, changing  
the definition of accidental-voided? so it returns the new list?



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 a  
call of it.  I have no idea what you mean by returns the new list.  What  
list?  I have no idea what you mean by the evaluated function: the  
function is called with each different context of the context hierarchy in  
turn.  Since it has a different context for each call, one can't evaluate  
the call in advance.


Put differently: I can't make head nor tail out of your comment.  I don't  
understand any sentence in it, actually not even any sentence part.


Perhaps you'd like to sketch some pseudo-code?  Hopefully I stand a better  
chance of understanding your proposal from that.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 of a rietveld issue, I'm moving this to patch-needs_work.


David, even though the patch is in git, would it be possible to upload it  
to rietveld anyway?  I find it much easier to comment on specific parts of  
code when there's the web interface.
(I personally probably don't know enough to comment in this one, but it  
would probably be much easier for Neil to be able to add psuedocode  
solutions this way)



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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://codereview.appspot.com/4384050


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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  
repetition of either accidental or key alteration).


Attachments:
0001-Issue-1471-Invalidate-alterations-upon-key-change-ra.patch  5.7 KB


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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


There are several downsides to this patch: the most important one likely  
being that it uses +nan.0 for signifying an unspecified alteration.   
Replacing this by 1000 had the unexpected result of causing extra naturals  
upon a clef change.  +nan.0, apart from being more appropriate, has no  
discernible sign, so it does not suffer from that defect.


Using #f lead to errors because alterations are compared using `='.  The  
code became more complex than expected because localKeySignature is getting  
_stuffed_ with non-altered pitches as well as altered ones.  If one does  
not leave them untouched, one gets nonsensical cautionary accidentals after  
clef changes.  Weeding them out altogether will change the accidental  
behavior, likely to the behavior that this strange measure is trying to fix  
in the first place.


Attachments:
0001-Issue-1471-Invalidate-alterations-upon-key-change-ra.patch  3.2 KB
junk.preview.png  2.9 KB


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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-change.patch  1.7 KB


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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 attempt the C half of the job until after 2.14 is out.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: missing accidental after clef change

[Dmytro O. Redchuk]

On Mon 10 Jan 2011, 12:29 Keith OHara wrote:
 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 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: 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
Thank you for submitting .)

-- 
  Dmytro O. Redchuk
  Bug Squad

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

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

[lilypond]

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  % 2.13.43 behaves the same
\relative c' {
  \key d \major
  \clef bass
  c4
  \clef treble
  c4
  \clef bass
  cis2  } % the sharp symbol is missing from the output

%  Workarounds: #(set-accidental-style 'piano)
%  or inspect the output near clef changes
%  and force accidentals, cis!2, when required

Attachments:
clef change.png  3.7 KB


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

missing accidental after clef change

[Keith OHara]

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 cancellation 
accidentals to
% be printed, if they would be printed for the same pitches without the clef 
change.

\version 2.12.3  % 2.13.43 behaves the same
\relative c' {
   \key d \major
   \clef bass
   c4
   \clef treble
   c4
   \clef bass
   cis2 } % the sharp symbol is missing from the output

%  Workarounds: #(set-accidental-style 'piano)
%  or inspect the output near clef changes
%  and force accidentals, cis!2, when required


The regression test accidental-clef-change.ly demonstrates that accidentals 
moving
away from the key signature are repeated after a mid-measure clef change.  This 
is
helpful, but might cause the problem above as a side-effect.

I would consider adding the extra accidentals in accidental-clef-change.ly to be
not as important as printing the within-measure cancellation accidentals.
The best behavior would be to have both: print accidental symbols if they would 
print
in the chosen accidental-style either in absence of the clef change, or with the
clef change treated as a reset to the key signature.attachment: missingAccidental.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Shane Brandes]

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, clefs, simply define where the
pitches fall on the staff and no other information. I am pretty sure I
have read that somewhere more authoritative than my cluttered head or
the internets, but can't unfortunately cite the actual book.


Shane

On Wed, Jan 5, 2011 at 9:12 PM, Reinhold Kainhofer
reinh...@kainhofer.com wrote:
 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 e.g. cello/bassoon parts/scores,
   which frequently switch between bass and tenor clef).
 
  Edition Peters, piano excerpt by Brissler from Mozart Requiem,
  Confutatis.  The g in the corni di bassotto entry is not even in the
  same octave, and still gets a natural.

 Also, in the Bärenreiter piano reduction of Bach's Christmas oratorio,
 measure 7 of the Choral Nr. 23 (Wir singen dir), p.72 of Bärenreiter BA
 5014a.


 There is a dis' in treble clef, followed by a d in bass clef. That d gets a
 natural cancellation.

 I have now also looked at several cello parts of my girlfriend. For example,
 in Dvorak's cello concerto (1955, Schott edition, Revision by Enrico Mainardi)
 there is the following image (notice the e natural after the clef with the e
 flat before the clef):
 http://picasaweb.google.com/lh/photo/RILU4L-9yytXkwELD607_FgxyXiAQ8P3wVPB2tHCMdU?feat=directlink

 Also, in Schumann's cello concerto there is the following measure (the last
 measure in the image has two d, where the natural is repeated after the
 clef!):
 http://picasaweb.google.com/lh/photo/A1Nm3cUd0o4W28xaJx001VgxyXiAQ8P3wVPB2tHCMdU?feat=directlink

 So, it seems there is no clear rule that a clef cancels all accidentals in the
 current measure so far. But most of the time, the accidental is given as some
 kind of cautinary/courtesy accidental.

 Cheers,
 Reinhold
 --
 --
 Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
  * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
  * http://www.fam.tuwien.ac.at/, DVR: 0005886
  * LilyPond, Music typesetting, http://www.lilypond.org

 ___
 lilypond-user mailing list
 lilypond-u...@gnu.org
 http://lists.gnu.org/mailman/listinfo/lilypond-user


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Reinhold Kainhofer]

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 e.g. cello/bassoon parts/scores,
   which frequently switch between bass and tenor clef).
  
  Edition Peters, piano excerpt by Brissler from Mozart Requiem,
  Confutatis.  The g in the corni di bassotto entry is not even in the
  same octave, and still gets a natural.
 
 Also, in the Bärenreiter piano reduction of Bach's Christmas oratorio,
 measure 7 of the Choral Nr. 23 (Wir singen dir), p.72 of Bärenreiter BA
 5014a.
 
 
 There is a dis' in treble clef, followed by a d in bass clef. That d gets a
 natural cancellation.

I have now also looked at several cello parts of my girlfriend. For example, 
in Dvorak's cello concerto (1955, Schott edition, Revision by Enrico Mainardi) 
there is the following image (notice the e natural after the clef with the e 
flat before the clef):
http://picasaweb.google.com/lh/photo/RILU4L-9yytXkwELD607_FgxyXiAQ8P3wVPB2tHCMdU?feat=directlink

Also, in Schumann's cello concerto there is the following measure (the last 
measure in the image has two d, where the natural is repeated after the 
clef!):
http://picasaweb.google.com/lh/photo/A1Nm3cUd0o4W28xaJx001VgxyXiAQ8P3wVPB2tHCMdU?feat=directlink

So, it seems there is no clear rule that a clef cancels all accidentals in the 
current measure so far. But most of the time, the accidental is given as some 
kind of cautinary/courtesy accidental.

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Xavier Scheuer]

On 4 January 2011 00:35, James Bailey james.lilyp...@googlemail.com wrote:

 It seems, at least according to section 1.1.3 on accidentals, that this is
 intended behavior:
 default

 This is the default typesetting behavior. It corresponds to
 eighteenth-century common practice: accidentals 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 that  accidentals are remembered to the end
of the measure in which they occur and only in their own octave
the c-natural in the second measure of my code _MUST_ be printed,
because it is in the same octave as the first note of the measure (cis2)
although written in a different clef.

Otherwise (as it is now, i.e. without printed natural) we should
conclude that the second note is a c-sharp also.
accidentals are remembered to the end of the measure in which they
occur and only in their own octave
_This is not the case_  We want a c-natural: the natural _MUST_ be
printed.

Cheers,
Xavier

-- 
Xavier Scheuer x.sche...@gmail.com

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[James Bailey]

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  % natural is not printed!!
  \clef bass cis2 \clef tenor c
 }
 
 I do not know what say references like Ross, Read about this but I do
 not think this should be the correct behaviour.
 IMHO this is not what a musician (and a user) expect:
 if we have a c-sharp and then a c-natural (at the same octave)
 _in the same measure_, then the natural __MUST__ be printed!
 This is also against what is said in the regtest
 ‘accidental-clef-change.ly’: Accidentals are reset for clef changes
 (note that this regtest works fine but the reported code does not).
 
 Could you investigate this?
 Thanks in advance.
 
 Cheers,
 Xavier
 
 PS: The only simple workaround is to use
  #(set-accidental-style 'piano)
 
 -- 
 Xavier Scheuer x.sche...@gmail.com


It seems, at least according to section 1.1.3 on accidentals, that this is 
intended behavior:
default
This is the default typesetting behavior. It corresponds to eighteenth-century 
common practice: accidentals 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:


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Accidental and clef change issue

[Xavier Scheuer]

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
}

I do not know what say references like Ross, Read about this but I do
not think this should be the correct behaviour.
IMHO this is not what a musician (and a user) expect:
if we have a c-sharp and then a c-natural (at the same octave)
_in the same measure_, then the natural __MUST__ be printed!
This is also against what is said in the regtest
‘accidental-clef-change.ly’: Accidentals are reset for clef changes
(note that this regtest works fine but the reported code does not).

Could you investigate this?
Thanks in advance.

Cheers,
Xavier

PS: The only simple workaround is to use
  #(set-accidental-style 'piano)

-- 
Xavier Scheuer x.sche...@gmail.com

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Phil Holmes]

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

I do not know what say references like Ross, Read about this but I do
not think this should be the correct behaviour.
IMHO this is not what a musician (and a user) expect:
if we have a c-sharp and then a c-natural (at the same octave)
_in the same measure_, then the natural __MUST__ be printed!
This is also against what is said in the regtest
‘accidental-clef-change.ly’: Accidentals are reset for clef changes
(note that this regtest works fine but the reported code does not).

Could you investigate this?
Thanks in advance.

Cheers,
Xavier

PS: The only simple workaround is to use
 #(set-accidental-style 'piano)

--
Xavier Scheuer x.sche...@gmail.com

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 as to whether this 
is correct, though.


--
Phil Holmes


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[David Kastrup]

Phil Holmes m...@philholmes.net writes:

 \relative c' {
  \clef bass cis2 c
  \clef tenor cis2 \clef bass c  % natural is not printed!!
  \clef bass cis2 \clef tenor c
 }


Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting?  Sensible 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 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 as to whether this is correct, though.

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 reason to assume accidentals
are reset.  If that was the underlying assumption for a clef change,
the key signature would be repeated.

-- 
David Kastrup


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Phil Holmes]

David Kastrup d...@gnu.org wrote in message 
news:87ei92oxo3@lola.goethe.zz...

Phil Holmes m...@philholmes.net writes:


\relative c' {
 \clef bass cis2 c
 \clef tenor cis2 \clef bass c  % natural is not printed!!
 \clef bass cis2 \clef tenor c
}



Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting?  Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.


Apologies. As you're probably aware, I'm a Windows man, and some postings 
don't quote properly using my mailreader.  As a result, 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 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 as to whether this is correct, though.


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 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 are reset for clef changes.


--
Phil Holmes
Bug Squad




___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[David Kastrup]

Phil Holmes m...@philholmes.net writes:

 David Kastrup d...@gnu.org wrote in message
 news:87ei92oxo3@lola.goethe.zz...
 Phil Holmes m...@philholmes.net writes:

 \relative c' {
  \clef bass cis2 c
  \clef tenor cis2 \clef bass c  % natural is not printed!!
  \clef bass cis2 \clef tenor c
 }


 Could you _please_ _never_ write an answer or comment in the _signature_
 of the original posting?  Sensible mailreaders don't quote the signature
 when replying, cutting away all of your content.

 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 configurations available also for
Windows mailreasers.

 As a result, If I want all the  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 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 as to whether this is correct, though.

 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 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 are reset for clef
 changes.

Which is likely the intent.  It is still not proper in my opinion.  I
would suppose that a conservative approach would be to mark all
non-signature accidentals in force at the time of the clef change in a
manner that will cause a (sometimes cautionary) accidental to be printed
regardless of whether the next note on the previously
accidental-equipped is in-signature or not.

That's sort of a half-reset of accidentals: it sets all non-signature
accidentals basically to unknown.

-- 
David Kastrup


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Reinhold Kainhofer]

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 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 are reset for clef changes.

I couldn't really find anything about accidentals in combination with clef 
changes in Stone or Read. The only thing that might apply is in Stone (p.54, 
item D. At Clef Changes:
If a clef changes withing a measure and the same note occurs before and after 
the clef change, the accidental must be repeated:
(Example in lilypond-notation:)
\relative c'' { \time 2/4 \clef treble a8[( cis,]) \clef bass cis[( e,]) }

In that example, the cis after the clef change gets a sharp. 
However, this example is only about repeating an accidental, not about whether 
all previous accidentals are actually reset and no natural is required.

As a musician, I would definiely appreciate if the natural sign is displayed, 
just to make it clear that it is a c and not a cis.



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

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[David Kastrup]

Reinhold Kainhofer reinh...@kainhofer.com writes:

 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 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 are reset for clef changes.


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

Edition Peters, piano excerpt by Brissler from Mozart Requiem,
Confutatis.  The g in the corni di bassotto entry is not even in the
same octave, and still gets a natural.



confutatis.pdf
Description: Adobe PDF document


-- 
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Phil Holmes]

David Kastrup d...@gnu.org wrote in message 
news:87aajqowbn@lola.goethe.zz...

Phil Holmes m...@philholmes.net writes:


David Kastrup d...@gnu.org wrote in message
news:87ei92oxo3@lola.goethe.zz...

Phil Holmes m...@philholmes.net writes:


\relative c' {
 \clef bass cis2 c
 \clef tenor cis2 \clef bass c  % natural is not printed!!
 \clef bass cis2 \clef tenor c
}



Could you _please_ _never_ write an answer or comment in the _signature_
of the original posting?  Sensible mailreaders don't quote the signature
when replying, cutting away all of your content.


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 configurations available also for
Windows mailreasers.


Hey - you're talking about M$ software here!  (FWIW I use the same software 
for mail and news, - partly since the lilypond newsgroups are also mailing 
lists.  I don't want to change).



As a result, If I want all the  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).


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 to print the accidental.  I'd welcome other
thoughts as to whether this is correct, though.


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 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 are reset for clef
changes.


Which is likely the intent.  It is still not proper in my opinion.  I
would suppose that a conservative approach would be to mark all
non-signature accidentals in force at the time of the clef change in a
manner that will cause a (sometimes cautionary) accidental to be printed
regardless of whether the next note on the previously
accidental-equipped is in-signature or not.

That's sort of a half-reset of accidentals: it sets all non-signature
accidentals basically to unknown.


It seems to me that, unless there is a cast iron rule in the literature (and 
it would appear not to be the case) then the best option might be to treat 
the clef change as a bar-line and use cautionaries as appropriate.


--
Phil Holmes
Bug Squad




___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[David Kastrup]

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 that there are sensible configurations available also for
 Windows mailreasers.

 Hey - you're talking about M$ software here!  (FWIW I use the same
 software for mail and news, - partly since the lilypond newsgroups are
 also mailing lists.  I don't want to change).

URL:http://oe-faq.de teaches German people how to stop annoying
everybody else even while using OE or its successor Windows Mail.  I
should be surprised if similar advice would not be available for
English-speaking people (anybody here on the list able to offer a
similar link?).

I don't understand how I get a crappy configuration shipped by factory
and know it is supposed to imply It's ok if I don't bother changing
it.  If you like the software you get from Microsoft and want to stay
with it, it is a one-time investment configuring it to behave sanely.

-- 
David Kastrup


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[James Bailey]

I don't know about this one. Certainly, the accidental should be (and is) 
printed. It's the naturals that aren't printed. Not even when changing octaves:
\new Staff \relative c' {
\time 6/4
\clef treble
cis dis fis
\clef tenor
c d f
\clef bass
cis dis fis
\clef treble
c' d f
}
Certainly, when changing octaves the accidental (sharp or flat), but I don't 
recall for naturals.

On Dec 28, 2010, at 12:41 PM, Phil Holmes wrote:

 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 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
 }
 
 I do not know what say references like Ross, Read about this but I do
 not think this should be the correct behaviour.
 IMHO this is not what a musician (and a user) expect:
 if we have a c-sharp and then a c-natural (at the same octave)
 _in the same measure_, then the natural __MUST__ be printed!
 This is also against what is said in the regtest
 ‘accidental-clef-change.ly’: Accidentals are reset for clef changes
 (note that this regtest works fine but the reported code does not).
 
 Could you investigate this?
 Thanks in advance.
 
 Cheers,
 Xavier
 
 PS: The only simple workaround is to use
 #(set-accidental-style 'piano)
 
 -- 
 Xavier Scheuer x.sche...@gmail.com
 
 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 as to whether this 
 is correct, though.
 
 --
 Phil Holmes
 
 
 ___
 bug-lilypond mailing list
 bug-lilypond@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-lilypond


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[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 e.g. cello/bassoon parts/scores, which
  frequently switch between bass and tenor clef).
 
 Edition Peters, piano excerpt by Brissler from Mozart Requiem,
 Confutatis.  The g in the corni di bassotto entry is not even in the
 same octave, and still gets a natural.

Also, in the Bärenreiter piano reduction of Bach's Christmas oratorio, measure 
7 of the Choral Nr. 23 (Wir singen dir), p.72 of Bärenreiter BA 5014a.


There is a dis' in treble clef, followed by a d in bass clef. That d gets a 
natural cancellation.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
attachment: Accidental_ClefChange.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental and clef change issue

[Patrick McCarty]

On Tue, Dec 28, 2010 at 1:28 PM, Michael Ellis
michael.f.el...@gmail.com wrote:
 The Dover Edition of the Beethoven Sonatas, a reproduction of the 1923
 Universal Edition (H. Schenker, ed.) has the attached in opus 27, no 2,
 second movement (Presto Agitato) mm 54,55.

 In the left hand of mm 54, 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 simply a courtesy accidental that corresponds
 to the one in the right hand.  I think it's most likely the latter.

I agree that it's the latter case.

This movement is (normally) performed at a very fast tempo where the
time difference between the A sharps and A naturals is about one
second (maybe less).  The courtesy accidentals are lifesavers,
especially if you are sight reading the movement at tempo.  ;)

Not related to your observation per se, but the movement is actually
in C-sharp minor.

Thanks,
Patrick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Multi-measure rest collides with clef change

[Reinhold Kainhofer]

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 isn't ideal for compressed rests: it
 spaces the rest to the barline, which is usually what we want for
 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...

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
\version 2.13.29

% \layout {
%   \context {\Score
% \override MultiMeasureRest #'spacing-pair =
%  #(lambda (grob)
% (cons 'break-alignment
%   (if ( (ly:grob-property grob 'measure-count) 1)
%  'break-alignment
%  'staff-bar)))
%}
% }

\relative c' {
  \compressFullBarRests
  R1 \clef alto |
  R1*13 | R1*14 |
  \clef alto c1 |
  R1*10| \time 4/2 \key fis \major R1*2 \time 4/4 R1 \clef treble
  e1 e e e
}
\header { tagline= ##f }
\paper {
  indent = 0\mm
  line-width = 160\mm - 2.0 * 0.4\in
  line-width = 160\mm
  force-assignment = #
  line-width = #(- line-width (* mm  3.00))
}


mmrest.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Multi-measure rest collides with clef change

[Neil Puttock]

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 see how we can accommodate every possibility (without
significant changes to the break-alignment code), but changing the
default to '(break-alignment . break-alignment) seems the best
compromise, with overrides for the exceptions (i.e., issue 915).

Cheers,
Neil

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Multi-measure rest collides with clef change

[Reinhold Kainhofer]

Am Samstag, 31. Juli 2010, um 14:06:34 schrieb Reinhold Kainhofer:
 Am Freitag, 30. Juli 2010, um 21:30:26 schrieben Sie:
  The default for 'spacing-pair isn't ideal for compressed rests: it
  spaces the rest to the barline, which is usually what we want for
  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 -- 
unless the rest is too close to a subsequent clef change. I don't know how 
this can be implemented, though :(

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial  Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Multi-measure rest collides with clef change

[Reinhold Kainhofer]

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., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
\version 2.13.29

\relative c' {
  \compressFullBarRests
  R1*27 |
  \clef alto c1 |
  R1*17 \clef treble
  c1
}
\header { tagline= ##f }
\paper {
  indent = 0\mm
  line-width = 160\mm - 2.0 * 0.4\in
  line-width = 160\mm
  force-assignment = #
  line-width = #(- line-width (* mm  3.00))
}
attachment: mmrest.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Multi-measure rest collides with clef change

[Neil Puttock]

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 to the barline, which is usually what we want for
single rests (especially if there are multiple staves).

I suppose a callback might suffice in most cases:

\override MultiMeasureRest #'spacing-pair =
#(lambda (grob)
   (cons 'break-alignment
 (if ( (ly:grob-property grob 'measure-count) 1)
'break-alignment
'staff-bar)))

Cheers,
Neil

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Grace notes cause clef-change positioning problem

[Jonathan Kulp]

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 it was an actual bug.


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?


Best,

Jon

--
Jonathan Kulp
http://www.jonathankulp.com

%
\version 2.11.62

% Grace notes in upper staff cause treble clef in
% viola part to go into 2nd bar


\new StaffGroup = strings 
  \new Staff = violinOne
  \relative c'' {
e4 e e e |
\grace { a,,8[( a'] } % the trouble is here
a'1)
  }
  \new Staff = viola
  \relative c'' {
\clef alto
a4 a a a
\clef treble |
a'1
  }



% Now without the grace notes, the clef is placed properly
% behind the barline


\new StaffGroup = strings 
  \new Staff = violinOne
  \relative c'' {
e4 e e e |
% \grace { a,,8[( a'] }
a1
  }
  \new Staff = viola
  \relative c'' {
\clef alto
a4 a a a
\clef treble |
a'1
  }


attachment: clef-prob.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes cause clef-change positioning problem

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

See also
http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Grace-notes
under Known issues and warnings.


  \new StaffGroup = strings 
\new Staff = violinOne
\relative c'' {
  e4 e e e |
  \grace { a,,8[( a'] } % the trouble is here
  a'1)
}
\new Staff = viola
\relative c'' {
  \clef alto
  a4 a a a
  \clef treble |
  \grace s4 a'1
}
  




best regards,
Wilbert Berendsen

-- 
LilyKDE, LilyPond for KDE: http://lilykde.googlecode.com/


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes cause clef-change positioning problem

[Wilbert Berendsen]

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://lilykde.googlecode.com/


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes cause clef-change positioning problem

[Jonathan Kulp]

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/user/lilypond/Grace-notes
under Known issues and warnings.



--
Jonathan Kulp
http://www.jonathankulp.com


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes cause clef-change positioning problem

[Werner LEMBERG]

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


Werner


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Grace notes cause clef-change positioning problem

[Jonathan Kulp]

It *does* use the horizontal space optimally, but I don't think I've 
ever seen a published score where it looks like this.  I'd have to check 
a notation style manual to know if it's a rule, but I'm pretty sure the 
clef is supposed to come before the barline.   Anyway the trick using 
\grace {s4} places the clef exactly where I want it, so there's no 
reason to change the current behavior.  Best,


Jon

Werner LEMBERG wrote:

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


Werner



--
Jonathan Kulp
http://www.jonathankulp.com


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 467 in lilypond: Two calls to set-octavation confound intervening clef change

[codesite-noreply]

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 listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 467 in lilypond: Two calls to set-octavation confound intervening clef change

[codesite-noreply]

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 message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 467 in lilypond: Two calls to set-octavation confound intervening clef change

[codesite-noreply]

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

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 467 in lilypond: Two calls to set-octavation confound intervening clef change

[codesite-noreply]

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 updates:
Labels: fixed_2_11_38

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 467 in lilypond: Two calls to set-octavation confound intervening clef change

[codesite-noreply]

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 listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Issue 412 in lilypond: bar number positioning influenced by clef change at end of previous system

[codesite-noreply]

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 received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings


___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond