Simon Albrecht | 27 Apr 10:05 2015

Completion_heads_engraver and dotted breve


Completion_heads_engraver doesn’t use dotted breve notes for its output, 
where smaller note values work as expected.

Thanks, Simon
bug-lilypond mailing list
bug-lilypond <at>
pls | 26 Apr 10:57 2015

LilyPond – Extending: value and guile prompt on same line despite newline procedure

Hey all,

at it says:

Note that both the value 2 and the guile prompt guile showed up on the same line. This can be avoided by calling
the newline procedure or displaying a newline character.

guile> (display a)(newline)
guile> (display a)(display "\n")

But when I try this in the scheme sandbox (LilyPond v2.19.15) on Ubuntu 14.10 (and Mac OS 10.9.5) I get:

guile> (display a)(newline)
guile> (display a)(display "\n")

Am I missing something?

Pierre Perol-Schneider | 25 Apr 15:32 2015

Missing 'crossStaff' warning?

Hi Bug Squad,

This thread follows a discussion on the French forum:

If I slightly modify this example:
and put the last d8 in the 'crossStaff' bloc:

\layout {
  \context {
    \consists #Span_stem_engraver

  \new PianoStaff <<
    \new Staff {
      <b d'>4 r d'16\> e'8. g8 r\!
      e'8 f' g'4 e'2
    \new Staff {
      \clef bass
      \crossStaff { <e g>4 e, g16 a8. c8 d }
      g8 f g4 c2
(Continue reading)

Simon Albrecht | 25 Apr 13:00 2015

ly:music-deep-copy and \relative


as Harm has pointed out, the following example gives unexpected (i.e. 
different) output:

\version "2.19"
repeat-note =
#(define-music-function (parser location music)(ly:music?)
   (make-sequential-music (list music (ly:music-deep-copy music))))

\absolute { c'1 \repeat-note c'' }
\relative c' { c \repeat-note c'1 }

There are several possible ways of handling this:
– Document it as a feature of ly:music-deep-copy in its search string. 
Users would have to circumvent it then.
– Modify ly:music-deep-copy to output both copies in the same octave. 
This would be most intuitive for what I think, since one would expect 
copies to be identical.
– Provide an optional (?) second argument to ly:music-deep-copy to 
choose between the two behaviours: abs-copy to use \relative only for 
determining the start of the first copy and start the second copy from 
the same absolute pitch; rel-copy to apply \relative also on the first 
note of the second copy (as in current behaviour).
– Use two dedicated functions for these two ways of handling it. What 
would they be named? I’d suggest ly:music-deep-copy-relative (current 
behaviour) and ly:music-deep-copy (new behaviour).

The third option would be easiest in terms of backward compatibility, 
the fourth is actually a variant of the second, with an additional 
(Continue reading)

pls | 25 Apr 12:31 2015

Learning Manual – simplify piano centered lyrics example?!

Hey all,

yesterday I stumbled across this example in the Learning Manual: In my opinion it
can and should be simplified.  Obviously there’s no need anymore for a GrandStaff to accept Lyrics.
\consists “Bar_engraver” has also become unnecessary, here. To make the example more consistent
with the text I’d use a PianoStaff instead of a GrandStaff like so:

\version "2.19.15"
upper = \relative c'' {
  \clef treble
  \key c \major
  \time 4/4

  a4 b c d

lower = \relative c {
  \clef bass
  \key c \major
  \time 4/4

  a2 c

text = \lyricmode {
  Aaa Bee Cee Dee

\score {
(Continue reading)

Urs Liska | 23 Apr 18:06 2015

Subdivided beams

I had the opportunity to have a look in the German translation of 
"Behind Bars" (which is BTW an exceptionally good translation. Usually I 
prefer reading this kind of books in the original language, but here I 
don't see any problems reading the translation).

There I found a rule where LilyPond's behaviour differs. The rule makes 
perfect sense to me, and the (very few) examples I could immediately 
find confirm it.

Consider the following example of beam subdivision

According to Gould (sorry, I don't own the book, so no page number 
available) the rhythmical organization is indicated by the number of 
remaining beams in the subdivisions. Depending on the length of the 
following group there should remain one or more beams.

In the example in the docs the third beat is correctly divided in two 
groups of a quaver's length, thus having a single beam in the middle. 
But in the fourth beat the first and the third subdivision should have 
*two* beams, indicating that they separate groups of a sixteenth note 
length each.

 From the description it seems that LilyPond doesn't do that and can't 
easily be talked into doing it, so this seems an "embarrassing" bug.

First question: is it possible to engrave that at all, i.e. create one 
beam with different subdivisions? If yes, this should be investigated, 
documented and made available with a reasonable interface (I mean an 
interface that is not more complicated or obscure than the subdivision 
(Continue reading)

Rob Tuley | 21 Apr 12:57 2015

Ugly output from \accidentalStyle piano

> I'm not top posting.

\version "2.18.2"
\new PianoStaff
% Output is consistent with the documentation, but the number of cautionary 
accidentals is ugly.
\accidentalStyle piano
\new Staff { c''4 c'' c'' c'' }
\new Staff { d'8 cis' d' cis' d' cis' d' cis' }
Dan Eble | 18 Apr 18:59 2015

alignBelowContext makes lyrics disappear

\version "2.19.16"

aNotes = \relative c'' { c4 d e f }
stanzaI = \lyricmode { La la la la }

\score {
    \context Staff = "upper" <<
      \new Voice = "melody" \aNotes

    \context Lyrics = "lyricsI" <<
      % The lyrics do not appear when this "alignBelowContext" is set.
      \set alignBelowContext = "upper"
      \lyricsto melody \stanzaI
H. S. Teoh | 18 Apr 17:01 2015

\partcombine interacts badly with \tag

% \partcombine should have produced a combined staff containing d'1 in
% the first bar, f'1 in the second and 3rd bars, and <f' d'>1 chords in
% the next 2 bars. However, it seems to interact badly with \tag, and
% the output has a missing f1' in the second bar, a stray rest in the
% 3rd bar, and a missing d'1 in the 4th bar. The first and last bars
% appear to be OK. (See attached .pdf file.)
% Removing the \removeWithTag line reveals that \partcombine has indeed
% combined the notes correctly, but apparently left the tags on the
% wrong notes, so that \removeWithTag deleted the wrong objects.
% Arguably, using \tag with \partcombine is a bad idea, since it can
% easily result in constructs that are probably not representable in a
% way that would make a subsequent \removeWithTag work correctly, but
% Lilypond should at least give a warning and/or reject such input
% instead of generating wrong output.

\version "2.18.2"

fluteIPart = {
    \tag #'layout { R1 }
    \tag #'midi { R1 }
    f'1 f' f' f'

fluteIIPart = {
    \tag #'layout { d'1 }
    \tag #'midi { d'1 }
    d'1 d'
(Continue reading)

Dan Eble | 18 Apr 16:41 2015

Ignored settings in \context X \with {}

\version "2.19.15"

\score {
  \new Staff <<
    % When these are added, the voice settings below are
    % ignored and the resulting warning is cryptic.
    \context Voice = "one" \with { \override NoteHead.color = #red }
    \context Voice = "two" \with { \override NoteHead.color = #blue }
      \context Voice = "one" \with { \voiceOne } { a' }
      \context Voice = "two" \with { \voiceTwo } { f' }
Risto Vääräniemi | 13 Apr 23:12 2015

Vertical spacing of Lyrics messed up by system-system-spacing.basic-distance


I'm trying to add some space between systems with
system-system-spacing.basic-distance inside the \paper block. In some cases
the basic-distance gives more uniform spacing than the padding.

However, it seems to mess up the vertical spacing of lyrics placed above a
staff. There seems to be too much space between the lyrics and the staff.
That doesn't affect the first staff but the next ones. The minimum-distance
does the same. Setting stretchability to 0 has no effect. I've attached an
image and an example.

If there are lyrics only on top of the staff the issue can be seen even
without modifying the basic-distance. The default value #12 is enough to
trigger this. If it is set to a much smaller value the spacing is OK. I'm
sorry if my example is confusing. I tried to cover both cases—with one and
two lines of lyrics.

Am I just missing something obvious? I tried to search for a similar bug
but found none so far.





(Continue reading)