Hans Adler | 6 Feb 01:11 2016

German documentation systematically calls ties slurs

German Lilypond documentation systematically translates "tie" as
"Bindebogen". However, German for "tie" is actually "Haltebogen", and
"Bindebogen" is the more common word for "slur". (Lilypond
documentation uses the word "Legatobogen" for "slur, which seems less
popular nowadays. A third synonym, "Schleifbogen", has fallen out of
use.)

Someone else already reported this documentation bug in October 2011.
At the time, Till Paala as the German translator promised to take care
of it eventually but also expressed interest in printed proof that
this is the actual terminology. (In addition to Wikipedia, which is
quite clear on the matter.)

To quote Musiktheorie für Dummies (visible on Google Books): "[...]
der sogenannte Bindebogen (Legatobogen), wie er in Abb. 15.5 zu sehen
ist. [...] (Nicht zu verwechseln mit Haltebögen, die dafür sorgen,
dass ein und dieselbe Note über mehrere Takteinheiten hinweg
'festgehalten' wird." The figure clearly labels several ties as
"Haltebogen" and several slurs as "Bindebogen".

All other printed sources I have seen agree, as does everyone I have
ever made music with.

Presumably this is very easy to fix by global search and replace for
someone who is already a contributor to the German translation. If
not, I am willing to take care of this problem myself (meticulously!)
provided that this fix is actually welcome and will be accepted. It
should be enough for now to just change "Bindebogen" to "Haltebogen".
I guess it is better not to change "Legatobogen" to the more popular
term "Bindebogen", as this might cause confusion for users familiar
(Continue reading)

Simon Albrecht | 5 Feb 00:00 2016
Picon

Crash with Completion_heads_engraver and a bare duration

Hello,

the following code crashes:

%%%%%%%%%
\version "2.19.36"
\layout {
   \context {
     \Voice
     \remove "Note_heads_engraver"
     \consists "Completion_heads_engraver"
   }
}
{ \breve }
%%%%%%%%%

Removing Note_heads_engraver is not essential to triggering the bug.

Best, Simon
paul booker | 2 Feb 13:48 2016
Picon

Install confirmation test file misleading

While I had no problems installing 2.18.2, moving to 2.29.36 was repeatedly
challenging, on Win 7 and 8.1.
The installation itself appears fine, but the test.ly file which is offered
to confirm the install and initiate newcomers has been misleading me.

It fails to generate a pdf. The log file gets as far as "Drawing systems..."
Or it's taking soooo long...?
I note that there is another LP icon in Public\Public Desktop and Lilypad
defaults to this one on first attempt to save test.ly.

As a newbie, I went through several installs of 2.19.36, 2.19.35, and
reverted to 2.18.2 to verify the test.ly procedure, mistaken in thinking
that it actually initiates the software, rather than initiating me. Things
went a lot better when I started ignoring it.
I also felt the test.ly took a long time to generate, but that was more
likely the result of repeated restarts and system house-keeping.

Paul
Urs Liska | 1 Feb 10:02 2016
Gravatar

Multiple beams too close to notehead

Hi all,

I've always found that beams with three or more beams look too tight,
but now reading Gould, p. 19 confirms that, and I consider this a
type-ugly bug:

According to Gould outer beams starting with the third should move away
from the notehead, and "beams should never be closer to the notehead
than the correct position of the semiquaver beam (2 1/2 spaces)".

Attached you'll find examples for three and four beams, and I expect
this to continue with more beams. I have colored the ones too close in
red and adjusted them (blue) to Gould's minimum distance.
It seems:

  * when the notehead is on a ledger line the rule of one clear staff
    space in the staff is correctly applied
  * when the notehead falls on one of the four outer staff lines the
    stem length is correct
  * when the notehead falls on the center line the stem has to be
    extended by 1/2 ss
  * when the notehead falls on any staff space (including the ones
    directly outside the staff) the stem has to be extended by 1 ss

Urs

Attachment (beams-too-close.ly): text/x-lilypond, 3981 bytes
Attachment (beams-too-close.pdf): application/pdf, 48 KiB
(Continue reading)

Urs Liska | 1 Feb 10:02 2016
Gravatar

Multiple beams too close to noteheaD

Hi all,

I've always found that beams with three or more beams look too tight,
but now reading Gould, p. 19 confirms that, and I consider this a
type-ugly bug:

According to Gould outer beams starting with the third should move away
from the notehead, and "beams should never be closer to the notehead
than the correct position of the semiquaver beam (2 1/2 spaces)".

Attached you'll find examples for three and four beams, and I expect
this to continue with more beams. I have colored the ones too close in
red and adjusted them (blue) to Gould's minimum distance.
It seems:

  * when the notehead is on a ledger line the rule of one clear staff
    space in the staff is correctly applied
  * when the notehead falls on one of the four outer staff lines the
    stem length is correct
  * when the notehead falls on the center line the stem has to be
    extended by 1/2 ss
  * when the notehead falls on any staff space (including the ones
    directly outside the staff) the stem has to be extended by 1 ss

Urs

Attachment (beams-too-close.ly): text/x-lilypond, 3981 bytes
Attachment (beams-too-close.pdf): application/pdf, 48 KiB
(Continue reading)

Simon Albrecht | 30 Jan 00:49 2016
Picon

No warning upon failed ‘align[Above|Below]Context’

Hello,

in this example

%%%%%%%%%%%
\version "2.19.35"
\new StaffGroup <<
   \new Staff = "A" { a'1 a' }
   { \skip 1 \new Staff = "C" \with { alignAboveContext = "B" } { c''1 } }
   { \skip 1 \new Staff = "B" \with { alignAboveContext = "A" } { b'1 } }
 >>
%%%%%%%%%%%

Lily can’t find context "B" when creating "C", so she silently prints 
"C" below "A". There should be a warning about this.

Best, Simon
_______________________________________________
bug-lilypond mailing list
bug-lilypond <at> gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Andy Deitrich | 29 Jan 16:29 2016
Picon

when adding \new Staff to a StaffGroup, ledger lines not rendered if clef is specified.

% The example here renders perfectly if \clef bass is removed
% but as is, the ledger lines in the new staff are not rendered.

\version "2.18.2"

\new StaffGroup \relative c {
	\time 6/8
	\new Staff
	c''2. | c2. 
	<<
	{<bes des f>2.~ | <bes des f>}
	\new Staff 
	\clef bass 
	{ges,,2. | f}
	>>
	}
Urs Liska | 27 Jan 10:19 2016
Gravatar

Automatically shift dynamics horizontally?

The fact that dynamics are always aligned to their notes can cause
unnecessarily large distances between staves as you can for example see
in the attached image generated from the following code.

\version "2.19.35"

off = {
% uncomment either of the following lines
%  \once \override DynamicText.X-offset = -3
%  \once \override DynamicText.X-offset = -3.5
}

\score {
  \new PianoStaff <<
    \new Staff \relative c'' {
      <<
        {
          \voiceOne
          c2 2
        }
        \new Voice {
          \voiceTwo
          e,4 c \off g \sf g'
        }
      >>
    }
    \new Staff \relative g {
      \clef bass
      <<
        {
(Continue reading)

Chris Yate | 23 Jan 18:37 2016
Picon

Poor line break decisions

Hi,

I'm seeing strange and unwanted line breaks in a number of scores, with the
2.19.35 build.

See attached PDF and zip file with input code. I suggest this is a bug --
ragged-right is OFF and it's breaking in a ridiculous place. I can suppress
this sort of thing with /noBreak but I shouldn't have to

Before someone complains that it's not a minimal example; this sort of
issue doesn't occur with short scores... ;-)

Thanks,

Chris
Attachment (Example.zip): application/zip, 111 KiB
Attachment (K487.pdf): application/pdf, 220 KiB
_______________________________________________
bug-lilypond mailing list
bug-lilypond <at> gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Urs Liska | 19 Jan 10:49 2016
Gravatar

git-cl traceback (timeout?)

When uploading a patch git-cl failed with the transcript below:

I'm not sure if that's caused by git cl (I had just pulled the newest
version) or if it's a simple time-out on my side, but:

a)
If it's a git-cl issue it should be fixed
b)
If it's a time-out such an error should be handled by git-cl
c)
This left me unclear of whether the issue had been created on Allura
(I can see that it did through the website but see b) )

Best
Urs

uliska <at> uliska-lmde-laptop:~/git/lilypond/source$ git cl upload master
 scm/lily.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Upload server: codereview.appspot.com (change with -s/--server)
Your browser has been opened to visit:

    https://codereview.appspot.com/get-access-token?port=8001

If your browser is on a different machine then exit and re-run
upload.py with the command-line parameter

  --no_oauth2_webbrowser

Issue created. URL: http://codereview.appspot.com/286820043
(Continue reading)

Urs Liska | 18 Jan 17:04 2016
Gravatar

ly:one-line-breaking doesn't properly handle indent value/side margins

Hi,

while testing the new #ly:one-line-auto-height-breaking I noticed some
issues with the already available #ly:one-line-breaking.

It seems the left and right margins are not properly handled in that mode:

The right margin is way too large to my eyes, which you can see when
setting right-margin to 0\cm.

The left margin is too small and doesn't respond to setting the indent
variable.
Quite the contrary, increasing the indent doesn't move the system to the
right but the instrument name to the left.

You can see both in the attached file. The image shows the unclipped
left/right/top margins compiled from the settings in the attached .ly file.

Urs
Attachment (one-line-breaking.ly): text/x-lilypond, 433 bytes
_______________________________________________
bug-lilypond mailing list
bug-lilypond <at> gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Gmane