Federico Bruni | 24 Nov 23:21 2015

ugly slur from chord to note


I think that the attached slur, both on Staff and TabStaff, is an ugly 
What do you think?

\version "2.19.31"

myMusic = \relative {
  \set minimumFret = 5
  <e'\2 cis( g-1> d2)

\score {
  \new StaffGroup <<
    \new Staff { \clef "treble_8" \myMusic }
    \new TabStaff \with {
      stringTunings = #guitar-tuning
    } \myMusic
  \layout { }

bug-lilypond mailing list
bug-lilypond <at> gnu.org
(Continue reading)

Simon Albrecht | 23 Nov 20:26 2015

Tweak on Clef’s X-extent influences on Beam’s vertical position

\version "2.19.31"
   \once\override Staff.Clef.X-extent = #'(0 . .8)
   \clef bass a, b, c

   \clef treble a'8
   \once\override Staff.Clef.X-extent = #'(0 . 0)
   \clef bass a, b, c

Yours, Simon
bug-lilypond mailing list
bug-lilypond <at> gnu.org
Simon Albrecht | 23 Nov 20:24 2015

Tweak on clef spills over


in the following example, the tweak on one clef spills over to the next:
\version "2.19.31"
   \clef treble a'8
   \tweak Clef.X-extent #'(0 . 0)
   \clef bass a, b, c

   \clef treble a'4

Yours, Simon
bug-lilypond mailing list
bug-lilypond <at> gnu.org
Andrew Bernard | 23 Nov 09:44 2015

Cannot locate libffi.so.6 on openSUSE Leap 42.1

The downloadable version of lilypond 2.19.32 will not run on openSUSE Leap 42.1 as it is unable to find
libffi.so.6, which is not installed on this OS.

The lilypond distribution includes this shared library in its usr/lib64 directory. But the installer
script only creates a lilypond wrapper start script referencing usr/lib and not usr/lib64:

me=`basename $0`
#export LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib"
export LD_LIBRARY_PATH="/home/andro/lilypond/usr/lib:/home/andro/lilypond/usr/lib64"
exec "/home/andro/lilypond/usr/bin/$me" "$ <at> "

If I add the lib64 directory as above, which contains libffi.so.6 all is well.

Why does the installer script omit the lib64 directory?

This is a defect because users of the downloadable lilypond cannot run it on openSUSE.

Trevor Daniels | 20 Nov 23:46 2015

Re: Irregularity in horizontal spacing

> Urs, you wrote Friday, November 20, 2015 10:19 PM
>> What I mean is: These final 16ths look pretty good, but they cause the
>> corresponding 8th notes in the top and bottom staff to be spaced pretty
>> irregularly. And in effect inacceptably.
>> As I have to get that score ready ASAP I can't wait for a proper fix (if
>> it should be considered a bug) but need a workaround that works better
>> than having to space the notes in all measures manually.
> Try:
>  \layout {
>    \context {
>      \Score
>      \override SpacingSpanner.common-shortest-duration = #(ly:make-moment 16)
>    }
>  }
> This will set the score much tighter though, so may not be acceptable.
> The actual value seems to be immaterial.

Actually, this seems better:

  \layout {
    \context {
      \override SpacingSpanner.uniform-stretching = ##t
(Continue reading)

Malte Meyn | 20 Nov 21:44 2015

collision: french beaming vs. articulation

Articulations at stem ends seem to ignore beams so french beaming leads 
to collisions:

\version "2.19.30"

   \override Stem.french-beaming = ##t
   \repeat unfold 8 g'16^>
bug-lilypond mailing list
bug-lilypond <at> gnu.org
Urs Liska | 20 Nov 16:37 2015

Irregularity in horizontal spacing


one more question.
I am right now experiencing an irregularity in the horizontal spacing
that is very small but still pretty annoying.

In the attached image you can see how the quavers are spaced out
irregularly. It is most obvious in the melody staff but you can also see
it in the piano left hand.

I have the impression that LilyPond takes the right hand figurations
into account and spaces the downward notes more closely because a
notehead can somewhat "slip" below the previous one.
This leads to the semiquavers being spaced out pretty good but the other
voices having ugly side effects.

I think this is a suboptimal spacing (so a bug report). Although it's
quite tiny it is absolutely inacceptable for a publication.

Is there a way to work around this without specifying offsets manually
(totally out of question for a three-page piece)?

(Continue reading)

Urs Liska | 20 Nov 10:32 2015

dynamics-barline collision

Hi list,

I am somewhat surprised that dynamics can still collide with barlines as
shown in the attached image. I thought this kind of issue had been quite
long overcome.

The \pp is defined in a Dynamics context, and of course I can work
around the collision by overriding self-alignment-X. But is there a
proper way to let LilyPond avoid that kind of collision automatically?


bug-lilypond mailing list
bug-lilypond <at> gnu.org
Urs Liska | 19 Nov 10:43 2015

SubdivideBeam gives undesired result when beaming over more than a quarter note

Since the fix for #4355, respectively commits 8fa2d858 and 0382ed88, it
is not possible anymore to subdivide beams that are longer than a
quarter note.

\version "2.19.32"

  \set subdivideBeams = ##t
  % This is correctly subdivided
  \set baseMoment = #(ly:make-moment 1 8)
  \repeat unfold 16 c'16

  % This should always keep one beam
  \set baseMoment = #(ly:make-moment 1 4)
  c' 16 [ \repeat unfold 14 c' c' ]


The behaviour is consistent with the feature request for #4355, namely:
the dividing beam should reflect the length of the following group,
which is 1/4 and results in no beam.

However, I think that this behaviour should be changed once more in that
subdivideBeam leaves *at least* one beam.

I admit I don't understand the modified code as per 0382ed88:

  // Set the count on each side of the stem
  // We need to run this code twice to make both the
  // left and the right counts work properly
(Continue reading)

Federico Bruni | 16 Nov 09:27 2015

NR 2.4.1, Fretted strings: \tabChordRepeats example

In the following example of \tabChordRepeats:

the purpose is showing that the strings/fret numbers used in TabStaff 
are kept when using q only if \tabChordRepeats is used. This chord:

<gis cis b>

will turn into 2-4-6 frets from 2nd to 4th string, while these chords:

<gis cis b-0>
<gis cis b\2>

will turn into 0-6-6 frets from 2nd to 4th string, as in the 

I believe that we should explain what's happening in a straightforward 
I would rewrite this parapraph this way (english speakers, please 
rewrite properly my words):

Chord constructs can be repeated by the chord repetition symbol
 <at> code{q}, as explained in  <at> ref{Chord repetition}. In combination
with tabulatures, its behavior of removing string and finger
numbers alongside with other events may lead to unwanted results,
e.g. different fret positions.  The command  <at> code{\tabChordRepeats}
will keep the fingering consistent across repetitions.  In the
following example, the default fingering for this chord (without
fingering indications) would be gis on 4th string, b on 3rd string,
cis on 2nd string.  As we use b-0, b will be on second string and
(Continue reading)

George Podkolzin | 14 Nov 08:17 2015

Big in repeat bar

\version "2.18.2"

\relative c' {
  c e c e
  \repeat volta 2 { \bar "[|:" c e g c }
  \alternative {
    % If I use \bar ":|]" instead of default repeat bar, there is no 
space between volta brackets.
    { c e, g2 \bar ":|]" } 
    { c4 g c,2 }
  \bar "|."