Dan Eble | 24 May 21:01 2015
Picon

engraving ends too early

% 2.19.20 does not engrave the lyrics and stops engraving the vocal
% staff before the end.  (Compare to 2.18.2.)  I haven’t tested MIDI.

\version "2.18.0"
\include "english.ly"

vocal = \relative c'' { R1 | f2 c }

% adding the skip makes 2.19.20 work
accomp = \relative c'' { c1 %{ s1 %} }

\score {
  <<
    <<      
      \new Staff <<
	\new Voice = "vocal" { \vocal }
      >>
      \new Lyrics <<
	\lyricsto "vocal" { \lyricmode { La la } }
      >>
    >>

    \new Staff <<
      \context Voice = "obligII" { \accomp }
    >>
  >>
}

_______________________________________________
bug-lilypond mailing list
(Continue reading)

pls | 23 May 16:39 2015
Picon
Picon

\chordmode vs. \notemode - On the relativity of absolute pitches

Hi all,

here’s another issue I posted somewhere and Carl answered:

>> 
>> P.P.S.: On a different note: some day I would like to get to know the
>> reason why in \chordmode the absolute pitches are one octave higher than
>> in note mode.  For chord names correct absolute pitches don¹t matter. But
>> they do when also using \chordmode in a Staff context.  Mixing both modes
>> is rather error prone.
> 
> I do not know the answer why, but I believe it is intentional.  There are
> comments in the code that indicate the original authors knew of the one
> octave shift.  I believe it was defined that way so that \chordmode c
> would give <c' e' g'>, since lilypond staffs have treble clefs by default.
> I believe it should probably be fixed.  The code is probably not hard to
> fix, but I think the convert-ly rule is nearly impossible (it's certainly
> beyond *my* python regexp-fu).
> Post a bug report, and let's get an issue created.

hth,
patrick
pls | 23 May 15:58 2015
Picon
Picon

misaligned fret labels in fret diagrams

Hi all,

in another thread I mentioned that I believe that the default vertical alignment of the fret labels in fret
diagrams is currently wrong.  The fret labels appear to be placed one fret above the lowest fret they are
referring to.  Carl asked me to post a bug report, so here it is:

\version "2.19.20"

#(set-global-staff-size 40)
<<
  \chords { d1:7 g1:7 a1:7 d1 g }
  \new FretBoards {
    <d-1 a-3 c'-1 fis'-4 a'-1>1
    <g,-1 d-3 f-1 b-2 d'-1 g'-1>1
    \transpose g a { <g,-1 d-3 f-1 b-2 d'-1 g'-1>1 }
    <d fis a>1
    <g b d'>1
  }
>>

This is what it currently looks like (misaligned-fret-labels.png):

red line: current vertical alignment
green line: correct vertical alignment

(The lowest fret is at the top of the diagram.  The first three diagrams should actually have a barre
indicator.  Carl is already working on a patch.  And while we’re at it: the alignment of the fingers in this
png also looks fishy to me!)

Here’s another illustration of where the fret labels should be positioned (correct-fret-labels):
(Continue reading)

Leah Velleman | 20 May 18:58 2015
Picon

Accessibility of score/bookpart header variables in headerMarkup

> Not top-posting

There are two related things I want to mention here — one is
an inconsistency between program behavior and documentation,
and one is a feature request.

First, the inconsistency: The manual
(http://www.lilypond.org/doc/v2.19/Documentation/notation/
creating-titles-headers-and-footers#titles-explained) says
that evenHeaderMarkup and other header/footer variables...

> can only access text fields from top-level \header blocks
> (which apply to all scores in the book)

In fact, this is not true. they can also access text fields
from \header blocks at levels as low as bookpart, as the
following MWE shows:

\version "2.19"
\paper {
  oddHeaderMarkup = \markup { \fromproperty #'header:title }
  evenHeaderMarkup = \markup { \fromproperty #'header:title }
  scoreTitleMarkup = \markup { }
  bookTitleMarkup = \markup { }
}

\book {
  \bookpart {
    \header { title = "foo bar baz" }
    \score {
(Continue reading)

Connor Harris | 20 May 07:28 2015
Picon

Hairpins ending on key changes

In Lilypond 2.18.2 and possibly later versions, hairpins that end at the 
beginning a measure are engraved with their right ends slightly left of 
the barline. This looks bad if the note follows a key change, as there may 
be considerable space (depending on how many accidentals are notated in 
the key change) between the barline and the note on which the hairpin 
properly ends. In this fragment, I'd prefer the hairpin to continue all 
the way to the dynamic marking under the second note.

{ \key ces \major bes'1\< \key cis \major bis'\f }
Simon Albrecht | 15 May 23:50 2015
Picon

Enhancement: more logical ambitus placement

Hello,

currently, ambitus are placed at the very beginning of the first system, 
before clef and key signature. However, its meaning depends on both: 
without a clef, the pitches are unspecified, and it’s confusing that 
accidentals are set based on a key which has not yet been ‘announced’ 
(See also <https://code.google.com/p/lilypond/issues/detail?id=762>; 
there used to be a workaround with \set Staff.keySignature = #'() which 
doesn’t work anymore).
I suggest to place the ambitus between key and time signatures, as seen 
in the attachment.
The values in the space-alists are more or less wild guesses, as I don’t 
have much experience with this kind of settings.
Do we really need an entry for ambitus in break-align-orders except for 
beginning of line?

Yours, Simon
Attachment (ambitus-place-comparison.ly): text/x-lilypond, 2222 bytes
_______________________________________________
bug-lilypond mailing list
bug-lilypond <at> gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
H. S. Teoh | 15 May 23:38 2015

\partcombine causes wrong tuplet bracket when tuplet begins with rest

% The triplet in the first argument to \partcombine is wrongly
% formatted in the output; the tuplet bracket only spans the two quarter
% rests, whereas it should span both rests and the single note.
%
% - Note: this is not the same as issue 913; padding the first voice
%   to have the same length as the second does not change the wrong
%   tuple bracket.
% - For some reason, deleting the r4 in the second voice makes the
%   problem disappear, for no apparent reason.
% - Starting the tuplet with a non-rest note also makes this problem go
%   away.
% - This problem does not occur if \partcombine is not used.

\version "2.19.19"
\score {
    \partcombine
        { \tuplet 3/2 { r r c'4 } }
        { R1 r4 }
}
musicus | 14 May 20:42 2015
Picon

\stopStaff and \break produce BarLine at the end of the upper line

\version "2.19.17"
		
{
  \stopStaff s1 \break 
  \startStaff a \stopStaff
}
Federico Bruni | 13 May 19:42 2015

Re: Fedora lilypond will not compile with large character set fonts

added quickly:
https://code.google.com/p/lilypond/issues/detail?id=4395

Il giorno mar 12 mag 2015 alle 12:31, Andrew Bernard 
<andrew.bernard <at> gmail.com> ha scritto:
> Hello Federico,
> 
> Thanks so much for this. If you did read my email, I explicit noted 
> it works just fine on Debian. It is an issue specific to Fedora. 
> There is no issue on Debian. And as mentioned, have you installed the 
> Linus Libertine fonts, and tried this on Fedora? I can reproduce it 
> on four Fedora machines.
> 
> It is only the downloadable 64 bit build running on Fedora 21 that 
> shows the problem.
> 
> I have just moved to Fedora from Debian which is how I encountered 
> the issue. I am sorry if this is not clear, but I did think I 
> mentioned it.
> 
> Andrew
> 
> 
> 
> On 12 May 2015 at 20:27:58, Federico Bruni (fede <at> inventati.org) wrote:
> 
> Andrew, I'm Cc-ing the list again.
> 
> I can reproduce the warning after installing the package 
> fonts-linuxlibertine and if I run lilypond with --verbose.
(Continue reading)

Federico Bruni | 12 May 12:26 2015

Re: Fedora lilypond will not compile with large character set fonts

Andrew, I'm Cc-ing the list again.

I can reproduce the warning after installing the package 
fonts-linuxlibertine and if I run lilypond with --verbose.
In Debian compilation is completed successfully.

Preprocessing graphical objects...
Grob count 43
[/home/fede/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-11.otf]
[/home/fede/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-13.otf]
[/home/fede/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-14.otf]
[/home/fede/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-16.otf]
[/home/fede/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-18.otf]
[/home/fede/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-23.otf]
Finding the ideal number of pages...
[linux_libertine_o_3.8662109375]
Fitting music on 1 page...
Drawing systems...
Element count 33
Layout output to `libertine-bugs.ps'...
[/usr/share/fonts/opentype/linux-libertine/LinLibertine_R.otf]
[/home/fede/lilypond/usr/share/lilypond/current/ps/music-drawing-routines.ps]
[/home/fede/lilypond/usr/share/lilypond/current/ps/lilyponddefs.ps]
Converting to `./libertine-bugs.pdf'...
Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH 
-r1200 -sDEVICE=pdfwrite -sOutputFile=./libertine-bugs.pdf 
-c.setpdfwrite -flibertine-bugs.ps'...

GPL Ghostscript 9.15 (2014-09-22)
(Continue reading)

Andrew Bernard | 12 May 10:32 2015
Picon

Fedora lilypond will not compile with large character set fonts

> I'm not top posting.

As of at least 2.19.19 onwards the 64 bit Linux binary download of lilypond
will not compile files on Fedora 21 if they use fonts with a large character
set, for example, the Linux Libertine fonts. The warnings issued by
ghostscript about embedding a subset of the fonts are treated by lilypond as
fatal errors.

This code will not compile:

% fedora-bug.ly

\version "2.19.19"

\paper
{
  #(define fonts
     (set-global-fonts
      #:roman "Linux Libertine O"
      #:sans "Linux Biolinum O"
      #:typewriter "Linux Libertine Mono O"
      #:factor (/ staff-height pt 20)
      ))
}

\relative c'' {
  c
}

Lilypond error message:
(Continue reading)


Gmane