2011/6/11 Graham Percival <gra...@percival-music.ca>:
> On Fri, Jun 10, 2011 at 07:05:34AM +0000, Keith OHara wrote:
>> Janek Warchoł <lemniskata.bernoullego <at> gmail.com> writes:
>>
>> > The change is almost certainly due to new beam collision algorithm.
>> > I'm forwarding this message to the development team so that they will
>> > know about this issue.
>> > I'm not sure if it's a bug, though
>>
>> I think it is a documentation issue. Sometimes we need to turn off the new
>> automatic collision avoidance by beams.
>
> Our existing policy is only to document bugs which are not likely
> to be fixed within a year or so. This is to avoid having lots of
> old warnings in the docs which nobody remembered to remove when
> making a bug fix.
>
> "The @knownissues should not discuss any issues that are in the
> tracker, unless the issue is Priority-Postponed. The goal is to
> discuss any overall architecture or syntax decisions which may be
> interpreted as bugs. Normal bugs should not be discussed here,
> because we have so many bugs that it would be a huge task to keep
> the @knownissues current and accurate all the time."
> http://lilypond.org/doc/v2.15/Documentation/contributor/section-organization
>
>
> Is this problem likely to be unfixed? Or is there a compelling
> reason to override our normal doc policy in this specific case?
> I am always happy to grant exceptions if there is a good reason.
I'd say that what we have here is an "architecture which may be
interpreted as bug".
(ofc it will be nice if the architecture was improved, but it isn't
necessary buggy)
Besides, we can avoid the problem with my doc patch by rearranging it.
See the attachment: i've changed it to be just another example, not a
@knownissue.
At the end of the day, i'd like to have something in the docs that
helps avoiding this problem with cross-staff stems and beam collision.
We may name it whatever we want.
HTH,
Janek
From 43b3e84cafe24db3e97912878dda3fed1cb1f6f6 Mon Sep 17 00:00:00 2001
From: Janek Warchol <lemniskata.bernoull...@gmail.com>
Date: Thu, 9 Jun 2011 22:39:40 +0200
Subject: [PATCH] doc: cross-staff chords and beam collision2
---
Documentation/notation/keyboards.itely | 35 ++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/Documentation/notation/keyboards.itely b/Documentation/notation/keyboards.itely
index f62b210..4c5c903 100644
--- a/Documentation/notation/keyboards.itely
+++ b/Documentation/notation/keyboards.itely
@@ -451,6 +451,41 @@ Chords that cross staves may be produced:
>>
@end lilypond
+Sometimes it is better to use stems from another staff
+for this purpose, because no problems with automatic beam collision
+avoidance arise. If the stems from the lower staff were used
+in the following example, it would be necessary to turn automatic
+beam collision avoidance off.
+
+@lilypond[verbatim,quote]
+\new PianoStaff <<
+ \new Staff = up
+ \relative c' {
+ <<
+ { r4
+ \override Stem #'cross-staff = ##t
+ \override Stem #'length = #19 % this is in half-spaces,
+ % so it makes stems 9.5 staffspaces long
+ \override Stem #'Y-offset = #-6 % stems are normally lenghtened
+ % upwards, so here we must lower the stem by the amount
+ % equal to the lenghtening - in this case (19 - 7) / 2
+ % (7 is default stem length)
+ e e e }
+ { s4
+ \change Staff = "bottom"
+ c, c c
+ }
+ >>
+ }
+ \new Staff = bottom
+ \relative c' {
+ \clef bass
+ \voiceOne
+ g8 a g a g a g a
+ }
+>>
+@end lilypond
+
@snippets
@lilypondfile[verbatim,lilyquote,texidoc,doctitle]
{indicating-cross-staff-chords-with-arpeggio-bracket.ly}
--
1.7.0.4
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
