Menu
▾
▴
1 Attachments
#76 beams should not collide with accidentals
Verified
nobody
None
Collision
2011-03-31
2006-09-21
Anonymous
No
Originally created by: *anonymous
Originally created by: gpermus@gmail.com
I'm not certain if this is a bug or not -- that is, I can't really see how
the typography could be improved. If we avoid the accidental completely,
then we'd end up with an ugly beam.
I marked this as high priority so it would be noticed quickly, not because
it's really important. (I expect that you'll agree that this is Not A Bug,
Because The Alternative Is Worse (tm)) Is this a good use of the priority
system, or should I just rank bug importance, instead of combining
importance and estimated-ease-of-fixing ?
\version "2.9.18"
\paper {ragged-right= ##t}
{ \time 6/8
\voiceOne
e''16
f''
e''
gis''
s 2
|
f'16
b'
d''
gis''
s2
|
}
Originally posted by: EWe...@gmail.com
Call it a bug or not...
Of course it's not difficult to change the beams' positions with
\once \override Voice.Beam #'positions = #'( 4.5 . 5.5 )
\once \override Voice.Beam #'positions = #'( 3.5 . 6.0 )
- and this doesn't look to ugly. But if we have to check and correct everything
manually...
A small remark about the importance - for guitar scores, polyphonic notation with
voiceOne, voiceTwo etc. is very important. Of course the notes' beams, annotations,
fingerings and others tend to move toward the margins of the single staff.
Regards
Luc
Originally posted by: hanw...@gmail.com
the problem is inherent in the configuration, yes, but that's why we use score based
formatting: by tweaking score parameters, the user can decide which tradeoff is
better. However, please ask the devel mailing list for comments if there are
problems that need direct attention.
Summary: beam scoring should take accidentals into account
Labels: -Type-Collision -Priority-High Type-Enhancement Priority-Low
Originally posted by: gpermus@gmail.com
HWN: sorry
Luc: it comes down to personal aesthics. I personally prefer the engraving with the
collision; forcing the beam to be above makes it look weird. In a perfect world,
we'd have an option like
Voice.avoidAllCollisions = ##t
which we could tweak as we liked. Failing that perfect world, we have the current
result.
Originally posted by: EWe...@gmail.com
... and I definitly prefer - even if it is time consuming - my tweaked version. One
reason for this is that the tweaked parts do not spoke out of their environment and
fit in very smoothly.
Please have a look yourself!
To the option "Voice.avoidAllCollisions": it would be nice to have it! Then you
could apply it and see what it looks like with and without and decide from there, if
there is need for tweaking. But I wouldn't rank this in a high priority, of course.
Originally posted by: v.villenave
(Reproduced in 2.11.47) The question is still unsolved.
Originally posted by: v.villenave
Another example:
\version "2.11.63"
\relative c' {
f,16 d' b' gis'
}
I'll keep a low priority but IMHO this may qualify as a collision.
Summary: beams should not collide with accidentals
Labels: -Type-Enhancement Type-Collision
Originally posted by: brownian.box@gmail.com
With 2.13.13 64ths behave better that 32ths (sometimes?..):
\version "2.13.13"
\relative c' {
g32[ ees']
g,64[ ees'!]
}
\paper{ ragged-right=##t }
Owner: ---
Originally posted by: brownian.box@gmail.com
oops, png attached
Originally posted by: k-ohara5...@oco.net
Work on issue 37 might resolve this issue as well, at least for manual beams.
Originally posted by: PhilEHol...@googlemail.com
The collision still occurs using 2.13.55, which fixes issue 37.
Originally posted by: pkx1...@gmail.com
an @knownissue has been added at the behest of mike S where use a similar example. in this case manual beaming stops the collisions.
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=5bdbfb56e8562fbbe36236f0dd2b00b539ef6ef1
Originally posted by: mts...@gmail.com
Fixed with the newest beam-collision-engraver
Status: Fixed
Originally posted by: ColinPKC...@gmail.com
Verified with 2.13.57
Status: Verified