Dot collides with flag when using magstep

[Nick Payne]

In guitar scores I usually increase the default stem length to minimise the 
amount of manual tweaking needed to prevent fingering indications from being 
overlaid by beams (I usually put fingering indications above treble notes and 
below bass notes).

If I do this, then in single-staff polyphony, with the treble voice stems 
always up, the dot on a dotted B eighth note intersects the flag. For some 
reason, it only happens with the note B, and only when I lengthen the stems.

%
\version "2.13.30"

\relative c' {
\time 3/4 \stemUp \autoBeamOff
e8. g8. b8. d8. f8.
\override Stem #'length-fraction = #(magstep 1)
e,8. g8. b8. d8. f8.
}
%

Nick

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Accidental overlaying stem

[Nick Payne]

I think I have reported this before - a beamed note with an accidental 
on a ledger line above the stave has the accidental colliding with the 
stem of the previous note. For different notes it happens at different 
heights above the stave and also seems to depend on the length of the 
stem of the previous note:


\version "2.13.30"

\relative c' {
\time 3/4
% \override Staff.Stem #'X-extent = #'(4 . 4)
\stemUp ais8[ bis'' ais] ais,[ bis'! ais] ais, [ais' ais] ais, 
[ais''! ais]

}

The second png shows the effect of activating the override, but the 
override doesn't work at all for the first B# and not to the extent that 
it should for the second last A#. How can I fix the problem - for the 
first B# in particular, as that's the actual problem I encountered in 
the score I'm engraving.


Nick
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidental overlaying stem

[Nick Payne]

On 25/08/10 02:36, Phil Holmes wrote:
"Nick Payne"  wrote in message 
news:4c72f469.4060...@internode.on.net...

I think I have reported this before - a beamed note with an accidental
on a ledger line above the stave has the accidental colliding with the
stem of the previous note. For different notes it happens at different
heights above the stave and also seems to depend on the length of the
stem of the previous note:

\version "2.13.30"

\relative c' {
\time 3/4
% \override Staff.Stem #'X-extent = #'(4 . 4)
\stemUp ais8[ bis'' ais] ais,[ bis'! ais] ais, [ais' ais] ais,
[ais''! ais]
}

The second png shows the effect of activating the override, but the
override doesn't work at all for the first B# and not to the extent that
it should for the second last A#. How can I fix the problem - for the
first B# in particular, as that's the actual problem I encountered in
the score I'm engraving.

Nick


Can't find where you've posted this before - not to the bug group, 
anyway.


This looks OK in 2.12.3 and so looks like a regression.  I've added it to
the bug tracker:

http://code.google.com/p/lilypond/issues/detail?id=1235

As a workaround, can you use 2.12.3?
I searched and found that my previous report was added to the bug list 
as http://code.google.com/p/lilypond/issues/detail?id=1099. However, 
that issue says that it's *not* a regression, and only deals with flats, 
saying that sharps or naturals don't collide, so I don't know if it's 
the same problem. I was finally able to fix the collision by overriding 
the accidental X-extent:


\version "2.13.30"

\relative c' {
\time 3/4
\stemUp ais8[ \once \override Staff.Accidental #'X-extent = #'(-4 . 
1.1) bis'' ais]
ais,[ bis'! ais] ais, [ais' ais] ais, [ \once \override 
Staff.Accidental #'X-extent = #'(-4 . 1.1) ais''! ais]

}

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Ledger lines overhanging end of stave

[Nick Payne]

The problem is more pronounced in the score where I encountered it, but 
this example demonstrates it.


%==
\version "2.13.31"

#(set-global-staff-size 18.5)

\paper { #(set-paper-size "a4") }

notes = \relative c'' {
\time 12/8
\key d \minor
\stemUp
e16 bes( a g f e d cis b a) g' e f d f a d cis d a d f b a
b16 f( e d c b a gis fis e) d' b c a c e a gis a( b c) gis a c
}

\score {
\notes
\layout { indent = 0 }
}
%==

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Default placement of string number indication does not avoid sloping beam

[Nick Payne]

\version "2.13.31"

\relative c'' {
a'16[ e c a e  a]
}

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: 2.13.32 not honouring margins and staves going off page

[Nick Payne]

On 05/09/10 09:33, Neil Puttock wrote:

On 5 September 2010 00:07, Nick Payne  wrote:
   

I haven't been able to reproduce this behaviour with a small example, but
I'm getting some staves in a score where lilypond tries to fit too many bars
and the stave goes past the margin and off the right-hand edge of the page,
and others where the the right-hand barline is at the correct margin but
notes go past the barline.
 

You have a few places where there are glissandos spanning a barline.
Line breaks will be forbidden at these points unless you allow
glissandos to be breakable:

\override Glissando #'breakable = ##t
   

Thanks. Adding

\override Staff.Glissando #'breakable = ##t

to the \score block fixed that problem, at the expense of increasing the 
page count by 50%. There's still a problem with vertical spacing in that 
with no bottom-system-spacing command in the paper block, the lowest 
stave on some pages overlays the page number at the bottom of the page. 
I had to add


bottom-system-spacing = #'((space . 4) (padding . 2) 
(stretchability . 0) (minimum-distance . 0))


to stop this happening.

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: 2.13.32 not honouring margins and staves going off page

[Nick Payne]

On 05/09/10 21:46, Nick Payne wrote:

On 05/09/10 09:33, Neil Puttock wrote:
On 5 September 2010 00:07, Nick Payne  
wrote:
I haven't been able to reproduce this behaviour with a small 
example, but
I'm getting some staves in a score where lilypond tries to fit too 
many bars
and the stave goes past the margin and off the right-hand edge of 
the page,
and others where the the right-hand barline is at the correct margin 
but

notes go past the barline.

You have a few places where there are glissandos spanning a barline.
Line breaks will be forbidden at these points unless you allow
glissandos to be breakable:

\override Glissando #'breakable = ##t

Thanks. Adding

\override Staff.Glissando #'breakable = ##t

to the \score block fixed that problem, at the expense of increasing 
the page count by 50%. There's still a problem with vertical spacing 
in that with no bottom-system-spacing command in the paper block, the 
lowest stave on some pages overlays the page number at the bottom of 
the page. I had to add


bottom-system-spacing = #'((space . 4) (padding . 2) 
(stretchability . 0) (minimum-distance . 0))
this short example shows the problem with staves going off the bottom of 
the page:


%=
\version "2.13.32"

%#(set-global-staff-size 24.5)

\relative c'' {
\time 12/8
\repeat unfold 64 {
\repeat unfold 3 { c,16 d e f g a b c d e f g }
\mark\markup { text }
}
}
%=

the console output contains

warning: couldn't fit music on page: overflow is 14.473369
warning: couldn't fit music on page: overflow is 18.535638
warning: couldn't fit music on page: overflow is 0.413630

and staves are going off the bottom of pages 1 & 2. If I add a paper 
block to put page numbers at the bottom of the page and retain a tagline 
on the final page, staves go off the bottom of all three pages:


%=
\paper {
#(define (not-last-page layout props arg)
(if (and (chain-assoc-get 'page:is-bookpart-last-page props #f)
(chain-assoc-get 'page:is-last-bookpart props #f))
empty-stencil
(interpret-markup layout props arg)))

#(set-paper-size "a4")
ragged-bottom = ##f
ragged-last-bottom = ##f
ragged-last = ##f
oddHeaderMarkup = \markup \fill-line { "" }
evenHeaderMarkup = \markup \fill-line { "" }
oddFooterMarkup = \markup \fill-line { \column {
\fontsize #2
\on-the-fly #not-last-page \on-the-fly #not-first-page 
\fromproperty #'page:page-number-string

\on-the-fly #last-page \fromproperty #'header:tagline
} }
evenFooterMarkup = \markup \fill-line { \column {
\fontsize #2
\on-the-fly #not-last-page \on-the-fly #not-first-page 
\fromproperty #'page:page-number-string

\on-the-fly #last-page \fromproperty #'header:tagline
} }
}
%=

Nick



___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

annotate-spacing causing error

[Nick Payne]

Some sort of strange interaction here (I'm running 2.13.37 amd64 on 
Linux). Lilypond barfs on this:


%
\version "2.13.37"

\header {
title = "Title"
}

\paper {
annotate-spacing = ##t
system-system-spacing #'space = #3
}

\relative c'' {
\repeat unfold 1024 { c4 }
}
%

with the following error in the console log:

Parsing...
Interpreting music... 
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232][240][248][256]

Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 or 2 pages...
Drawing 
systems.../usr/local/lilypond/usr/share/lilypond/current/scm/stencil.scm:667:41: 
In procedure assoc in expression (assoc-get sym spacing-spec ...):
/usr/local/lilypond/usr/share/lilypond/current/scm/stencil.scm:667:41: 
Wrong type argument in position 2 (expecting association list): ((space 
. 3) . #)


If I remove either one of the two settings in the paper block, then it 
builds without error. So either setting is valid on its own, but not if 
both are used together.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Repeated embedded fonts in PDF documentation

[Nick Payne]

When I look at the metadata for the PDF versions of the documentation, 
it shows hundreds and hundreds of embedded fonts. Or more correctly, it 
shows subsets of the same fonts embedded, in some cases, hundreds of 
times over.


For example, open the 2.13.55 NR in Adobe Reader, and go to the Fonts 
tab of the document properties. It takes about 15 or 20 seconds for 
acroread to enumerate all the embedded fonts and fill the list box, and 
if you scroll down you can see that some fonts, such as DejaVuSans and 
Emmentaler, have subsets embedded many many times over.


If I open the one of the manuals in Acrobat (full version) and select 
the Reduce File Size option from the Document menu, which consolidates 
fonts, then when that eventually finishes - depending on file size, it 
can take many hours to complete - I find that the size of the PDF file 
has been reduced by 40-50%.


The number of duplicate font subsets has skyrocketed at some point 
during the 2.13 development process. Every few subversions I make myself 
a PDF portfolio of the PDF docs, and I normally run a Reduce File Size 
on the individual PDF docs first, as that reduces the size of the 
portfolio from ~50Mb to ~30Mb. This used to take around 20-30 minutes to 
process all the English PDF docs, but it now takes about an hour for the 
docs excluding the NR, and many hours for the NR alone, and nearly all 
the processing time is spent in consolidating duplicate fonts.


Without knowing what mechanism is used for producing the PDF docs, I 
wonder if *not* subsetting fonts would produce smaller documentation 
files, as there would then be no need to include hundreds of different 
subsets of the same font.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Repeated embedded fonts in PDF documentation

[Nick Payne]

On 24/03/11 19:35, Werner LEMBERG wrote:

I just tried using pdfsizeopt without pngout, jbig2, or multivalent,
and got about a 25% reduction in the size of the Notation Reference
pdf.

Better than nothing, actually.

However, the `multivalent' part is the real optimization engine (and
this is exactly the problematic bit w.r.t. the license); using it you
should get far more impressive numbers.


I setup pdfsizeopt, including multivalent, and ran the 2.13.55 docs 
through it, then created a PDF portfolio with an embedded index using 
Acrobat. The end result was a 34.8MB file containing


extending.pdf
internals.pdf
learning.pdf
notation.pdf
snippets.pdf
usage.pdf
web.pdf

For comparison, a portfolio from the same files shrunk in Acrobat is 
29.9Mb, and one made from the PDFs straight out of the doc tarball is a 
bit over 50Mb.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

programming error: cannot align on self: empty element

[Nick Payne]

The following minimal example generates the error "programming error: 
cannot align on self: empty element" in the console log.


\version "2.13.58"

\relative c' {
\tempo 4 = 72
\override Score.MetronomeMark #'stencil = ##f
c4 c c c
}

Comment out either the \tempo indication or the override and the error 
goes away. I use this combination of commands in the \score block quite 
often if I want the midi output to play at a particular speed for 
proofing, but I don't want a tempo indication to appear in the score. 
Having the error appear in the log doesn't seem to affect either the 
midi output or the printed score.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Slurs are better than ties at automatically avoiding collisions

[Nick Payne]

See below. If I have a tie between the two Gs in the top voice, it 
collides with the beam. If I fake the tie with a slur, it automatically 
avoids the beam.


\version "2.13.58"

\relative c'' {
<< { g'2 ~ g }
\\ { s1 }
\\ { b,8 g a b ~ b a b a }
\\ { g,2 g }
>>
}

\relative c'' {
<< { g'2( g) }
\\ { s1 }
\\ { b,8 g a b ~ b a b a }
\\ { g,2 g }
>>
}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Beaming problem introduced with 2.13.60

[Nick Payne]

Example below demonstrates (a couple of bars taken from Bach's 
chaconne). This problem did not exist in versions prior to 2.13.60:


%=
\version "2.13.60"
\language "english"

\relative c' {
\time 3/4
\key d \minor
\stemUp
d,16 bf''' bf gs gs f f d d b gs e |
\stemDown cs a'' a fs fs ef ef c \stemUp c a fs( d) |
}
%=

The console log contains

Drawing systems...
programming error: No viable beam quanting found.  Using unquanted y value.
continuing, cross fingers
/home/nick/lilypond/examples/test.ly:9:18: warning: weird stem size, 
check for narrow beams

\stemDown
  cs a'' a fs fs ef ef c \stemUp c a fs( d) |
programming error: No viable beam quanting found.  Using unquanted y value.
continuing, cross fingers
/home/nick/lilypond/examples/test.ly:9:39: warning: weird stem size, 
check for narrow beams

\stemDown cs a'' a fs fs ef ef
   c \stemUp c a fs( d) |

And the output looks like


<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Drawing systems...ERROR: In procedure min: ERROR: Wrong type: lilyvartmpbh

[Nick Payne]

This code used to work for me about a year ago, but when I try to build 
it using 2.13.60, I get the weird error shown in the console log output 
at the bottom. Is this a bug or not? I'm running 2.13.60 on Ubuntu 10.04 
amd64.


%===
\version "2.13.60"

% e.g. \spanbox #-8 #'(-1 . -1)
spanbox = #(define-music-function (parser location yval shorten) 
(number? pair?) #{

\once \override TextSpanner #'style = #'line
\once \override TextSpanner #'bound-details #'left #'text = \markup 
{ \draw-line #'(0 . $yval) }
\once \override TextSpanner #'bound-details #'right #'text = 
\markup { \draw-line #'(0 . $yval) }
\once \override TextSpanner #'bound-details #'left #'padding = 
#(car $shorten)
\once \override TextSpanner #'bound-details #'right #'padding = 
#(cdr $shorten)

#})

\relative c' {
\spanbox #-8 #'(-1 . -1) c4\startTextSpan c c c\stopTextSpan
}
%===

Processing `/home/nick/lilypond/examples/box.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...ERROR: In procedure min:
ERROR: Wrong type: lilyvartmpbh


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Drawing systems...ERROR: In procedure min: ERROR: Wrong type: lilyvartmpbh

[Nick Payne]

On 26/04/11 22:26, m...@apollinemike.com wrote:

On Apr 26, 2011, at 8:02 AM, Nick Payne wrote:


This code used to work for me about a year ago, but when I try to build it 
using 2.13.60, I get the weird error shown in the console log output at the 
bottom. Is this a bug or not? I'm running 2.13.60 on Ubuntu 10.04 amd64.

%===
\version "2.13.60"

% e.g. \spanbox #-8 #'(-1 . -1)
spanbox = #(define-music-function (parser location yval shorten) (number? 
pair?) #{
\once \override TextSpanner #'style = #'line
\once \override TextSpanner #'bound-details #'left #'text = \markup { 
\draw-line #'(0 . $yval) }
\once \override TextSpanner #'bound-details #'right #'text = \markup { 
\draw-line #'(0 . $yval) }
\once \override TextSpanner #'bound-details #'left #'padding = #(car 
$shorten)
\once \override TextSpanner #'bound-details #'right #'padding = #(cdr 
$shorten)
#})

\relative c' {
\spanbox #-8 #'(-1 . -1) c4\startTextSpan c c c\stopTextSpan
}
%===

Processing `/home/nick/lilypond/examples/box.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...ERROR: In procedure min:
ERROR: Wrong type: lilyvartmpbh


This should do the trick - the problem is that you need to quasiquote the list 
and then unquote the temp variable that lilypond uses to store yval.

spanbox = #(define-music-function (parser location yval shorten) (number? 
pair?) #{
\once \override TextSpanner #'style = #'line
\once \override TextSpanner #'bound-details #'left #'text = \markup { 
\draw-line #`(0 . ,$yval) }
\once \override TextSpanner #'bound-details #'right #'text = \markup { 
\draw-line #`(0 . ,$yval) }
\once \override TextSpanner #'bound-details #'left #'padding = #(car 
$shorten)
\once \override TextSpanner #'bound-details #'right #'padding = #(cdr 
$shorten)
#})

\relative c' {
\spanbox #-8 #'(-1 . -1) c4\startTextSpan c c c\stopTextSpan
}


Thanks. That fixes it. After experimenting a bit more with the two 
different single quotes (` and ') in different set and override 
expressions, it seems that in some situations, only ` is acceptable, in 
some only ' is acceptable, and in some situations either ` or ' are both 
valid. this seems a bad situation to have so far as making it easy to 
write valid lilypond source code.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Beam avoidance of other voices and stem length for beamed notes

[Nick Payne]

Latest LP development version has inconsistency. See below.

\version "2.13.61"

\relative c'' {
\time 3/4
\key d \minor
<<
{ 8 r  r s }
\\
{ d, r cis r r4 }
\\
{ g'8. f16 g8. bes16 a8. g16 }
>>
}

Nick

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Beam avoidance of other voices and stem length for beamed notes

[Nick Payne]

On 05/05/11 13:21, m...@apollinemike.com wrote:

On May 4, 2011, at 3:16 PM, Nick Payne wrote:


Latest LP development version has inconsistency. See below.

\version "2.13.61"

\relative c'' {
\time 3/4
\key d \minor
<<
{8 r  r s }
\\
{ d, r cis r r4 }
\\
{ g'8. f16 g8. bes16 a8. g16 }
}


The disparity in results comes (I think) from the fact that the flag of the 
stem in the left example ends after the beam begins on the X axis, and thus, 
the beam collision engraver moves the beam up to avoid the entire stem+flag.  
In the second example, on the other hand, the flag's rightmost X point falls to 
the left of the beam's leftmost X point.
Yes, that seems to be why, as if I add \once \override NoteColumn 
#'force-hshift = #1 at the beginning of voice 2, then both beams 
intersect the rests above. However, if the collision avoidance mechanism 
does shift the note at the beginning of voice 2 horizontally, why 
doesn't it shift the note far enough for the stem/beam to avoid the flag 
on the note in voice 1, given that it manages to do so successfully for 
the second beat in the bar. Or is that difference due to the notes in 
the two voices being a third apart on the first beat but only a second 
apart on the second beat.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Stem length on beamed notes incorrect in 2.13.61

[Nick Payne]

A bar excerpted from the Mertz guitar transcription of Ständchen. When I 
last worked on this score about ten months ago, using 2.13.27, I didn't 
have the problem with the beam on the notes in the middle voice being 
placed below the stem of the note in the lower voice - the beam was 
placed along the bottom line of the stave - see 2.13.27.png, a screen 
shot from the PDF I made at the time:


\version "2.13.61"

\relative c'' {
\time 3/4
<<
{ cis'2. }
\\
{ a,,2. }
\\
{ \stemDown a''8 e  e  e }
>>
}

Nick
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering positioning problem 2.13.61

[Nick Payne]

See below. As soon as I add strokefingering to the chord, it affects the 
position of the fingering indication for the B. I don't have a previous 
version of LP installed to test against, but this behaviour has changed 
somewhere along the line, as the actual score I was working on looks 
fine on the PDF I created using 2.13.42 but shows the same wierdness as 
my test example when built with 2.13.61.


\version "2.13.61"

\relative c' {
\override Fingering #'staff-padding = #'()
\override StrokeFinger #'staff-padding = #'()
\override Fingering #'add-stem-support = ##f
\override StrokeFinger #'add-stem-support = ##t
\set fingeringOrientations = #'(up down)
\set strokeFingerOrientations = #'(up)
8[  b-0-\rightHandFinger #3 >]

}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering positioning problem 2.13.61

[Nick Payne]

On 27/05/11 21:17, Phil Holmes wrote:
- Original Message - From: "Nick Payne" 


To: ; 
Sent: Friday, May 27, 2011 11:35 AM
Subject: Fingering positioning problem 2.13.61



See below. As soon as I add strokefingering to the chord, it affects the
position of the fingering indication for the B. I don't have a previous
version of LP installed to test against, but this behaviour has changed
somewhere along the line, as the actual score I was working on looks
fine on the PDF I created using 2.13.42 but shows the same wierdness as
my test example when built with 2.13.61.

\version "2.13.61"

\relative c' {
\override Fingering #'staff-padding = #'()
\override StrokeFinger #'staff-padding = #'()
\override Fingering #'add-stem-support = ##f
\override StrokeFinger #'add-stem-support = ##t
\set fingeringOrientations = #'(up down)
\set strokeFingerOrientations = #'(up)
8[  ]
}



AFAICS it's completely identical on 2.13.61, 2.13.3, 2.13.42 and 
2.13.40. What do you believe has changed?


I pulled the old PDF and ly score off a backup. Here's the bar from the 
score as it appears on the 2.13.42 PDF, and here's what the same bar 
looks like when I create the PDF with 2.13.61.


Nick
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Slurs and PhrasingSlurs with simultaneous start or end

[Nick Payne]

The automatic positioning of Slurs and PhrasingSlurs that both either 
start or finish on the same note is not very good. See below. Commercial 
scores that I have where this happens position the two slurs so that 
they don't intersect or touch, as in the second bar where the 
PhrasingSlur has been tweaked so that it doesn't intersect the slur:


\version "2.14.0"

offsetPhrasingSlurPos =
  #(define-music-function (parser location offsets) (pair?)
#{
   \once \override PhrasingSlur #'positions = #(lambda (grob)
 `(,(+ (car $offsets) (cdar (ly:phrasingslur::calc-control-points 
grob))) .
   ,(+ (cdr $offsets) (cdr (cadddr 
(ly:phrasingslur::calc-control-points grob))

#})

\relative c'' {
\time 3/4
\slurDashed
c16\(( d) e f g8\) c,8 d16\(( c) b a\)
\offsetPhrasingSlurPos #'(0.3 . 0) c16\(( d) e f g8\) c,8 
\offsetPhrasingSlurPos #'(0.3 . 0) d16\(( c) b a\)

}


Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: programming error: no solution found for Bezier intersection

[Nick Payne]

On 14/09/11 08:34, Trevor Daniels wrote:

Nick Payne wrote Tuesday, September 13, 2011 11:25 PM

The problem is that the score is quite large, and the log gives no 
indication at all about where the error is coming from. I guess I can 
try commenting out different sections to see if I can isolate where 
the error is happening.


Nick, if it helps, the problem will be with either a slur or
a tie.  The code is trying to find the height of a slur or a
tie at a particular x value (or vice versa) and finds no slur
or tie at that point.  Some code in this area is relatively
new, so it is possible you have hit a code error.  If you
can narrow it down that would be very helpful (or it may
help you find a problem in your ly code :).


Ok, the following small example reproduces the error on my system with 
2.15.11:


%==
\version "2.15.11"

\language "english"

fingering = {
\set fingeringOrientations = #'(left)
\set strokeFingerOrientations = #'(up)
\override Fingering #'avoid-slur = #'inside
\override StrokeFinger #'avoid-slur = #'outside
}

\relative c'' {
\fingering
16( b)
}
%==

If I get rid of the right hand fingering then the error goes away, and 
if I comment out the override for StrokeFinger #'avoid-slur then the 
error also goes away but the log contains the warning:


/home/nick/lilypond/examples/test.ly:14:13: warning: Ignoring grob for 
slur: StrokeFinger. avoid-slur not set?

16( b)

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

No pf dynamic marking in dynamic-scripts-init.ly

[Nick Payne]

I've been setting some Carcassi studies. His Op60 No 8 has a "pf" 
dynamic marking at one point (see 
http://erato.uvt.nl/files/imglnks/usimg/c/c8/IMSLP34430-PMLP03629-ribs0980_06.pdf, 
fifth stave on the first page), which does not exist in Lilypond. I 
added the variable definition pf = #(make-dynamic-script "pf") to my ly 
source, but is there any reason why this should not be added to 
dynamic-scripts-init.ly? That already contains fp as a dynamic marking, 
why not pf?


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Apparently bogus warning with 2.15.12

[Nick Payne]

On 26/09/11 21:47, Reinhold Kainhofer wrote:

Hi Nick,

Am Monday, 26. September 2011, 11:27:01 schrieb Nick Payne:

I'm setting Bach's BWV853 (Prelude from WTC 1), using showLastLength to
just engrave the last six bars added, and as I add bars I'm getting
warnings about unterminated ties that come and go as the bars are added.
The reason I say the warning is bogus is because there are no ties
across barlines anywhere in the piece, and when I have a look at the
bar(s) being complained of, there are no ties anywhere near.

Can you try to create a minimal example that shows the problem. Your error
messages simply don't give us any code to try to reproduce (and then track
down) the problem.


I haven't been able to create a small example that gets the bogus 
warning in the log, but while trying to do so I managed to reproduce 
what looks like a related/similar problem. When I build the example 
below using showLastLength, Lilypond puts a tie between the first two 
notes of bar 6, though there is no tie there in the source, and if I 
comment out showLastLength to build the entire score, the tie there 
disappears.


%=
\version "2.15.12"
\language "english"

showLastLength = R1.*4

\relative c'' {
\time 3/2
fs2 r4 r8 fs b4. d8 |
2 r4 r8 b e4. g8 |
as,2 r4 r8 cs e,4 ~ e16 d e fs |
d4. cs16 b d'2  |
 r4 r16 d c b c4. a8 |
b2   |
s2 r4 r16 b a g a4. fs8 |
g4. fs16 e 2  |
 r4 r16 fs e d cs( d) cs( d) e d e cs |
}
%=

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Error in lily-library.scm with 2.15.14

[Nick Payne]

I have one score that when when I try to build it with 2.15.14, I get 
the following output in the log.


===
Processing `/home/nick/lilypond/chaconne.ly'
Parsing...
Interpreting music... 
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232][240][248][256]

Preprocessing graphical objects...
Interpreting music... 
/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:210:5: 
In procedure ly:book-process in expression (process-procedure book paper 
...):
/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:210:5: 
Wrong type (expecting exact integer): -1.0

===

I don't get this error with any of the other scores I have built with 
2.15.14, and this score built without error on 2.14 and hasn't been 
modified since except by running convert-ly against it.


I copied the score across to a Windows machine with 2.14.2 installed, 
changed the \version statement back to 2.14.2, and it built without any 
error. The machine with 2.15.14 installed is running Ubuntu amd64.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Error in lily-library.scm with 2.15.14

[Nick Payne]

On 20/10/11 23:54, Neil Puttock wrote:

On 20 October 2011 11:23, Nick Payne  wrote:


I don't get this error with any of the other scores I have built with
2.15.14, and this score built without error on 2.14 and hasn't been modified
since except by running convert-ly against it.

Can you recompile the code using the verbose option?  That should give
a better indication of where Guile is complaining.


This would seem to be the relevant part of the log file when I use that 
option:


Interpreting music...
elapsed time: 0.15 secondsBacktrace:
In unknown file:
   ?:  0* [lilypond-main ("chaconne.ly")]
In /usr/local/lilypond/usr/share/lilypond/current/scm/lily.scm:
 808:  1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...)
 808:  2* [lilypond-all ("chaconne.ly")]
 821:  3  (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...)
 832:  4* [for-each # ("chaconne.ly")]
In unknown file:
   ?:  5* [# "chaconne.ly"]
In /usr/local/lilypond/usr/share/lilypond/current/scm/lily.scm:
 834:  6* (let* (# # #) (if separate-logs #) (if ping-log #) ...)
 845:  7* [lilypond-file # "chaconne.ly"]
 872:  8  [catch ly-file-failed # #args)>]

In unknown file:
   ?:  9* [#]
In /usr/local/lilypond/usr/share/lilypond/current/scm/lily.scm:
 873: 10* [ly:parse-file "chaconne.ly"]
In /usr/local/lilypond/usr/share/lilypond/current/ly/init.ly:
  48: 11* (let* ((book-handler #)) (cond (# #) (# #)))
  51: 12  (cond (# #) (# #))
In /usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:
...
 210: 13  [ly:book-process # #< Output_def> ...]

/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:210:5: 
In procedure ly:book-process in expression (process-procedure book paper 
...):
/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:210:5: 
Wrong type (expecting exact integer): -1.0



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Error in lily-library.scm with 2.15.14

[Nick Payne]

On 20/10/11 21:50, David Kastrup wrote:

Nick Payne  writes:


I have one score that when when I try to build it with 2.15.14, I get
the following output in the log.

===
Processing `/home/nick/lilypond/chaconne.ly'
Parsing...
Interpreting
music... 
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232][240][248][256]
Preprocessing graphical objects...
Interpreting
music... 
/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:210:5:
In procedure ly:book-process in expression (process-procedure book
paper ...):
/usr/local/lilypond/usr/share/lilypond/current/scm/lily-library.scm:210:5:
Wrong type (expecting exact integer): -1.0
===

I don't get this error with any of the other scores I have built with
2.15.14, and this score built without error on 2.14 and hasn't been
modified since except by running convert-ly against it.

I copied the score across to a Windows machine with 2.14.2 installed,
changed the \version statement back to 2.14.2, and it built without
any error. The machine with 2.15.14 installed is running Ubuntu amd64.

There are no guarantees that working code relying on undefined behavior
will continue to work in later Lilypond versions.  And even defined
behavior may change.

Try boiling down your source file to a level where it still triggers the
error but is small enough to post here.


This creates the error:

\version "2.15.14"

\paper {
first-page-number = -1
}

\relative c {
c1
}

Setting first page number to -1 seems to be the problem. In the actual 
score, I set this, in conjunction with custom headers and footers, to 
start page numbering with 1 on the third page - first page is the 
frontispiece, second page is blank.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Problem with glissandi in 2.15.15

[Nick Payne]

I'm using glissandi to indicate slides in fingering. The following code 
should give me a glissando between the fingering digits (it did in older 
versions), but on 2.15.15 I get no glissando at all:


\version "2.15.15"

\relative c'' {
\override Fingering #'staff-padding = #'()
\once \override Glissando #'extra-offset = #'(0 . 1.4)
4\glissando 
}

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Problem with music function in 2.15.18

[Nick Payne]

There's a music function I use in virtually every guitar score I've done 
with Lilypond, to move glissandi that I use to indicate that a finger 
should be kept on a string when moving frets. I just downloaded and 
installed 2.15.18 (Linux amd64 version running on Ubuntu 10.04), and the 
parameters to the function no longer seem to be being recognised as the 
correct type. The short example below shows the problem.


\version "2.15.18"

\language "english"

guide = #(define-music-function (parser location padleft padright shift 
missacc) (number? number? pair? boolean?) #{

\once \override Glissando #'bound-details #'left #'padding = #$padleft
\once \override Glissando #'bound-details #'right #'padding = 
#$padright

\once \override Glissando #'extra-offset = #$shift
\once \override Glissando #'bound-details #'right 
#'end-on-accidental = #$missacc

\once \override Glissando #'breakable = ##t
\once \override Glissando #'after-line-breaking = ##t
#})

\relative c' { \guide #1 #1 #'(0 . 1.4) ##f \glissando  }

Trying to build this gives the following in the log:

==
Processing `/home/nick/lilypond/examples/test.ly'
Parsing...
:2:91: error: GUILE signaled an error for the expression 
beginning here
\once \override Glissando #(quote bound-details) #(quote left) 
#(quote padding) = #


   $padleft
:3:92: error: GUILE signaled an error for the expression 
beginning here
\once \override Glissando #(quote bound-details) #(quote right) 
#(quote padding) = #


$padright
:4:59: error: GUILE signaled an error for the expression 
beginning here

\once \override Glissando #(quote extra-offset) = #
   $shift
:5:102: error: GUILE signaled an error for the expression 
beginning here
\once \override Glissando #(quote bound-details) #(quote right) 
#(quote end-on-accidental) = #


  $missacc
/home/nick/lilypond/examples/test.ly:14:45: error: error in #{ ... #}
\relative c' { c4 c \guide #1 #1 #'(0 . 1.4)
 ##f \glissando  }
Interpreting music...
warning: type check for `extra-offset' failed; value `#' 
must be of type `pair of numbers'

Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test.ps'...
Converting to `./test.pdf'...
Unbound variable: $padleft
Unbound variable: $padright
Unbound variable: $shift
Unbound variable: $missacc
fatal error: failed files: "/home/nick/lilypond/examples/test.ly"
=

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Problem with music function in 2.15.18

[Nick Payne]

On 13/11/11 13:51, Carl Sorensen wrote:

On 11/12/11 2:17 PM, "Nick Payne"  wrote:


There's a music function I use in virtually every guitar score I've done
with Lilypond, to move glissandi that I use to indicate that a finger
should be kept on a string when moving frets. I just downloaded and
installed 2.15.18 (Linux amd64 version running on Ubuntu 10.04), and the
parameters to the function no longer seem to be being recognised as the
correct type. The short example below shows the problem.

\version "2.15.18"

\language "english"

guide = #(define-music-function (parser location padleft padright shift
missacc) (number? number? pair? boolean?) #{
 \once \override Glissando #'bound-details #'left #'padding =
#$padleft
 \once \override Glissando #'bound-details #'right #'padding =
#$padright

I believe you now use just $padright instead of #$padright


Thanks. I found that I'd forgotten to run convert-ly against the include 
file containing this (and other) music functions.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Unable to find file "lily.scm" in load path

[Nick Payne]

I was using Lilypond with no problems yesterday (2.15.20 on Ubuntu 10.04 
amd64). I noticed 2.15.21 on lilypond.org this morning, so I downloaded 
the Linux 64 version, ran uninstall-lilypond, and installed 2.15.21. On 
any attempt to run Lilypond I got:


GNU LilyPond 2.15.21
ERROR: In procedure primitive-load-path:
ERROR: Unable to find file "lily.scm" in load path

I rebooted, ran uninstall-lilypond again and reinstalled 2.15.20 from 
the download I still had from my initial install of 2.15.20, but got 
exactly the same error message from 2.15.20, so I ran lilypond inside 
strace. This seems to be the relevant portion of the strace log file - 
the last couple of dozen lines:


stat("/home/nick/lilypond/scm/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/home/nick/lilypond/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/usr/local/lilypond/usr/bin/../share/guile/1.8/lily.scm", 
0x7fffc5d00d00) = -1 ENOENT (No such file or directory)
stat("/usr/share/guile/site/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/usr/share/guile/1.8/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/usr/share/guile/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No such 
file or directory)

write(2, "ERROR", 5)= 5
write(2, ": ", 2)   = 2
write(2, "In procedure ", 13)   = 13
write(2, "primitive-load-path", 19) = 19
write(2, ":\n", 2)  = 2
write(2, "ERROR", 5)= 5
write(2, ": ", 2)   = 2
write(2, "Unable to find file ", 20)= 20
write(2, "\"", 1)   = 1
write(2, "lily.scm", 8) = 8
write(2, "\"", 1)   = 1
write(2, " in load path", 13)   = 13
write(2, "\n", 1)   = 1
close(4)= 0
close(5)= 0
exit_group(1)   = ?

lily.scm is in /usr/local/lilypond/usr/share/lilypond/current/scm, which 
is where I would expect it to be. Any suggestions on how to fix this 
problem?


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Unable to find file "lily.scm" in load path

[Nick Payne]

On 08/12/11 12:06, Nick Payne wrote:
I was using Lilypond with no problems yesterday (2.15.20 on Ubuntu 
10.04 amd64). I noticed 2.15.21 on lilypond.org this morning, so I 
downloaded the Linux 64 version, ran uninstall-lilypond, and installed 
2.15.21. On any attempt to run Lilypond I got:


GNU LilyPond 2.15.21
ERROR: In procedure primitive-load-path:
ERROR: Unable to find file "lily.scm" in load path

I rebooted, ran uninstall-lilypond again and reinstalled 2.15.20 from 
the download I still had from my initial install of 2.15.20, but got 
exactly the same error message from 2.15.20, so I ran lilypond inside 
strace. This seems to be the relevant portion of the strace log file - 
the last couple of dozen lines:


stat("/home/nick/lilypond/scm/lily.scm", 0x7fffc5d00d00) = -1 ENOENT 
(No such file or directory)
stat("/home/nick/lilypond/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/usr/local/lilypond/usr/bin/../share/guile/1.8/lily.scm", 
0x7fffc5d00d00) = -1 ENOENT (No such file or directory)
stat("/usr/share/guile/site/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/usr/share/guile/1.8/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No 
such file or directory)
stat("/usr/share/guile/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No such 
file or directory)

write(2, "ERROR", 5)= 5
write(2, ": ", 2)   = 2
write(2, "In procedure ", 13)   = 13
write(2, "primitive-load-path", 19) = 19
write(2, ":\n", 2)  = 2
write(2, "ERROR", 5)= 5
write(2, ": ", 2)   = 2
write(2, "Unable to find file ", 20)= 20
write(2, "\"", 1)   = 1
write(2, "lily.scm", 8) = 8
write(2, "\"", 1)   = 1
write(2, " in load path", 13)   = 13
write(2, "\n", 1)   = 1
close(4)= 0
close(5)= 0
exit_group(1)   = ?

lily.scm is in /usr/local/lilypond/usr/share/lilypond/current/scm, 
which is where I would expect it to be. Any suggestions on how to fix 
this problem?


Well, my really ugly hack that gets LP to run was to copy the entire 
contents of /usr/local/lilypond/usr/share/lilypond/current into 
~/lilypond. After that it runs without error.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Unable to find file "lily.scm" in load path

[Nick Payne]

On 08/12/11 18:07, David Kastrup wrote:

Nick Payne  writes:


I was using Lilypond with no problems yesterday (2.15.20 on Ubuntu
10.04 amd64). I noticed 2.15.21 on lilypond.org this morning, so I
downloaded the Linux 64 version, ran uninstall-lilypond, and installed
2.15.21. On any attempt to run Lilypond I got:

GNU LilyPond 2.15.21
ERROR: In procedure primitive-load-path:
ERROR: Unable to find file "lily.scm" in load path

I rebooted, ran uninstall-lilypond again and reinstalled 2.15.20 from
the download I still had from my initial install of 2.15.20, but got
exactly the same error message from 2.15.20, so I ran lilypond inside
strace. This seems to be the relevant portion of the strace log file -
the last couple of dozen lines:

stat("/home/nick/lilypond/scm/lily.scm", 0x7fffc5d00d00) = -1 ENOENT
(No such file or directory)
stat("/home/nick/lilypond/lily.scm", 0x7fffc5d00d00) = -1 ENOENT (No
such file or directory)
stat("/usr/local/lilypond/usr/bin/../share/guile/1.8/lily.scm",
0x7fffc5d00d00) = -1 ENOENT (No such file or directory)
lily.scm is in /usr/local/lilypond/usr/share/lilypond/current/scm,
which is where I would expect it to be. Any suggestions on how to fix
this problem?

Sure you don't have an executable or even a dead symbolic link in
/home/nick/lilypond or /home/nick/bin or so?


No, I ran "find ~/ -name lilypond" and nothing was found. I also 
uninstalled lilypond from /usr/local/lilypond, and then installed LP not 
as root, so that it installed instead to /home/nick/lilypond and put its 
scripts and links in /home/nick/bin. When I run LP after installing 
there, I get the same error, and if I run inside strace, I see very 
similar lines in the log file - just slightly different paths:


stat("/home/nick/lilypond/scm/lily.scm", 0x7fff45b27450) = -1 ENOENT (No 
such file or directory)
stat("/home/nick/lilypond/lily.scm", 0x7fff45b27450) = -1 ENOENT (No 
such file or directory)
stat("/home/nick/lilypond/usr/bin/../share/guile/1.8/lily.scm", 
0x7fff45b27450) = -1 ENOENT (No such file or directory)


So for the moment I'm back to installing to /usr/local/lilypond and 
copying the contents of /usr/local/lilypond/usr/share/lilypond/current 
to ~/lilypond.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Unable to find file "lily.scm" in load path

[Nick Payne]

On 08/12/11 19:44, David Kastrup wrote:

Nick Payne  writes:


No, I ran "find ~/ -name lilypond" and nothing was found.

env | grep lilypond

is also empty?


Aha! (strikes forehead). That was it. I completely forgot that I had 
come across the LILYPOND_DATADIR env variable and experimented to see if 
I could use it to point to a dir containing include files. I had unset 
it after finding that it gave the error but forgot to remove it from 
.profile.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Chord fingering placement bug?

[Nick Payne]

See below. If the note with the accidental appears first in the chord, 
then the fingering for the other note correctly avoids the accidental. 
If the order of the notes is reversed, the fingering collides with the 
accidental. I don't know if this is related to issue 1222 
(http://code.google.com/p/lilypond/issues/detail?id=1222), also 
concerning fingering colliding with an accidental.


\version "2.15.23"

\relative c'' {
\set fingeringOrientations = #'(left)
1

}

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Chord fingering placement bug?

[Nick Payne]

On 05/01/12 07:58, Nick Payne wrote:
See below. If the note with the accidental appears first in the chord, 
then the fingering for the other note correctly avoids the accidental. 
If the order of the notes is reversed, the fingering collides with the 
accidental. I don't know if this is related to issue 1222 
(http://code.google.com/p/lilypond/issues/detail?id=1222), also 
concerning fingering colliding with an accidental.


\version "2.15.23"

\relative c'' {
\set fingeringOrientations = #'(left)
1

}


p.s. I also think that Lilypond's default spacing places fingering is 
too far away from the note. It looks better, and is less confusing (see 
also issue 220) with the following overrides:


\relative c'' {
\set fingeringOrientations = #'(left)
1
\override Fingering #'padding = #0.3
\override Staff.AccidentalPlacement #'left-padding = #0

}

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Stem separating dot from notehead

[Nick Payne]

With overlapping parts, Lilypond defaults to separating a dot from its 
notehead by placing the overlapping stem in between. According to Gould 
(p.57) this is incorrect. The overlapped stem should be placed after the 
dot.


\version "2.15.25"

\relative c' {
<< { c2 s c'4. } \\ { g2. s4 c, } \\ { s1 g'4 } >>
}

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Error in footnote documentation

[Nick Payne]

In the NR at 
http://lilypond.org/doc/v2.15/Documentation/notation/creating-footnotes#automatic-footnotes, 
the documentation on automatic footnotes says (asterisks are mine) "The 
command \footnote must come *before* the grob that the footnote is being 
attached to". At 
http://lilypond.org/doc/v2.15/Documentation/notation/creating-footnotes#manual-footnotes, 
it states "Like automatic footnotes, manual \footnote commands must come 
*after* the grob that the footnote is annotating", which conflicts with 
the earlier statement.


Nick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Strange interaction between page number settings and footnote

[Nick Payne]

In the following, for some reason the footnote appears three times on 
the first page, overlaying the lowest stave, and once each on the second 
and third pages. Also, on page two, the footnote is below the page 
number, and on page three it is above the tagline.


It's some interaction with the on-the-fly settings in the paper block, 
as if I comment out \on-the-fly #not-last-page, then the footnote on 
page three disappears, and if I also comment out \on-the-fly #last-page 
\fromproperty #'header:tagline, then the footnotes on pages two and 
three disappear and the footnote appears only twice on the first page.


\version "2.15.31"

\paper {
#(define (not-last-page layout props arg)
(if (and (chain-assoc-get 'page:is-bookpart-last-page props #f)
(chain-assoc-get 'page:is-last-bookpart props #f))
empty-stencil
(interpret-markup layout props arg)))

oddHeaderMarkup = \markup \null
evenHeaderMarkup = \markup \null
oddFooterMarkup = \markup \fill-line { \center-column {
\on-the-fly #print-page-number-check-first
\on-the-fly #not-first-page
\on-the-fly #not-last-page
\fromproperty #'page:page-number-string
\on-the-fly #last-page \fromproperty #'header:tagline
}
}
evenFooterMarkup = \oddFooterMarkup
}

\relative c' {
\footnote #'(0.5 . 5) #'NoteHead \markup { Now is the time for all 
good men to come to the aid of the party }

c4 c c c
\repeat unfold 900 { c4 }
}

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Subdivide beam bug 2.15.33?

[Nick Payne]

I would expect that all four beams should be subdivided, but only the 
second beam in the bar is being subdivided:


\version "2.15.33"

\relative c' {
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\set baseMoment = #(ly:make-moment 1 8) \set subdivideBeams = ##t
\times 4/6 { \repeat unfold 24 { c16 } } |
}

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Error in documentation

[Nick Payne]

In the snippets documentation, the second of the coda symbols (beginning 
of the third stave of output) in the snippet 
http://lilypond.org/doc/v2.15/Documentation/snippets/repeats#repeats-positioning-segno-and-coda-_0028with-line-break_0029 
is shifted to the left and only partly visible in the snippet output.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Font size setting explanation is a bit misleading in documentation

[Nick Payne]

In the text formatting documentation at 
http://lilypond.org/doc/v2.15/Documentation/notation/formatting-text, 
when talking about the size of characters, the phrasing at one point is: 
"the font size can be set to an absolute value with \fontsize". Maybe 
this should be changed to something like "the font size can be set to an 
particular numeric value with \fontsize", as \fontsize is still relative 
to the staff size, and the size of the font will change if the staff 
size changes.


Rather strangely, \abs-fontsize, which does set the absolute size of the 
font without regard to the staff size, doesn't get a mention in this 
section, but only in s.A.9.1.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Footnote documentation error

[Nick Payne]

The documentation at 
http://lilypond.org/doc/v2.15/Documentation/notation/creating-footnotes 
for both automatic and manual footnotes says that the \footnote command 
must come *before* the grob to which the footnote is being attached. 
This doesn't seem to be the case. Here the \footnote commands are after 
the notes to which they are attached, and they work fine:


\version "2.15.37"

\paper {
#(set-paper-size "a7")
}

\header {
tagline = ##f
}

\relative c'' {
c4 c-\footnote #'(0.7 . 2) #'NoteHead \markup\teeny { Automatic 
footnote }
c c-\footnote "a)" #'(0.7 . 2) #'NoteHead \markup\teeny { \concat { 
\lower #0.8 \super { a) } "Manual footnote" } }

}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Problem with articulate.ly

[Nick Payne]

The example below builds without error and gives the output I want. 
However, if I include articulate.ly, then the output is garbaged even 
though I haven't used \unfoldRepeats \articulate, and I get the 
following warnings in the log:


/home/nick/lilypond/examples/test.ly:8:59: warning: already have a beam
\times 4/6 { a32[( g) fis( g) \appoggiatura { fis16
   [ g] } a32 g] }
warning: cannot end slur
warning: unterminated slur

%=
\version "2.15.37"

%\include "articulate.ly"

\relative c'' {
\times 4/6 { a32[( g) fis( g) \appoggiatura { fis16[ g] } a32 g] }
}
%=


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering overlapping on chord

[Nick Payne]

On a chord containing a second, the fingering numerals overlap each 
other if placed on the left. This isn't a regression, the output is the 
same on 2.14.2 and 2.15.38.


\relative c'' {
\set fingeringOrientations = #'(left)
4
}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Beaming regression 2.15.39 compared to 2.14.2

[Nick Payne]

In 2.14.2, the output for the second bar beams all five eighth notes 
together, as I would expect. In 2.15.39, the first eighth note is not 
beamed with the others:


\relative c'' {
\time 3/4
c8 c c c c c
r c c c c c
}
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Beaming override problem

[Nick Payne]

If I set beamExceptions to beam 32nd notes by fours in 4/4 time, this 
has the side effect of changing the beaming of 8th notes:


%=
\version "2.15.40"

changeBeaming = \set beamExceptions =
#'((end . (((1 . 32) . (4 4 4 4 4 4 4 4)

\relative c'' {
c8 c c c c c c c
\repeat unfold 32 { c32 }
}
\relative c'' {
\changeBeaming
c8 c c c c c c c
\repeat unfold 32 { c32 }
}
%=

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering placement problem

[Nick Payne]

In a chord containing a second, if I place the fingering above the notes 
to avoid having the fingering numerals overlapping each other (see 
https://code.google.com/p/lilypond/issues/detail?id=2541), then the 
numerals default to being placed much higher above the noteheads than is 
normal or if either of the notes in the second is omitted from the chord:


\version "2.15.43"

\relative c'' {
\set fingeringOrientations = #'(left)
\override Fingering #'staff-padding = #'()
\override Fingering #'add-stem-support = ##f
4   
}

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering placement problem

[Nick Payne]

On 19/08/12 16:46, Nick Payne wrote:
In a chord containing a second, if I place the fingering above the 
notes to avoid having the fingering numerals overlapping each other 
(see https://code.google.com/p/lilypond/issues/detail?id=2541), then 
the numerals default to being placed much higher above the noteheads 
than is normal or if either of the notes in the second is omitted from 
the chord:


\version "2.15.43"

\relative c'' {
\set fingeringOrientations = #'(left)
\override Fingering #'staff-padding = #'()
\override Fingering #'add-stem-support = ##f
4   
}

A similar problem happens with fingerings where the same note is played 
simultaneously on two different strings. This happens quite frequently 
when transcribing the lute music of Silvius Leopold Weiss for guitar:


\version "2.15.43"

\relative c' {
\set fingeringOrientations = #'(down)
\override Fingering #'staff-padding = #'()
\override Fingering #'add-stem-support = ##f
4
}

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Lilypond editing environments

[Nick Payne]

On 06/09/12 16:27, Janek Warchoł wrote:
> On Thu, Sep 6, 2012 at 1:21 AM, Nick Payne  
> wrote:
>> Elysium (the Eclipse plugin for Lilypond editing) is not listed in the
>> documentation as one of the editing environments for Lilypond. It should
>> probably be there
>> http://elysium.thsoft.hu/
> I didn't found licensing information on their website; since Lily is a
> GNU project we can recommend only Free Software.  If Elysium is Free
> Software, please send an information about it to bug-lilypond@gnu.org

The licensing is EPL: https://code.google.com/a/eclipselabs.org/p/elysium/.

EPL is listed as an open source license at
http://opensource.org/licenses/alphabetical.

Nick
<https://code.google.com/a/eclipselabs.org/p/elysium/>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Composer header field with large staff size

[Nick Payne]

With a large staff size and a longish composer field, the composer name
runs off the right-hand edge of the page, even though there is plenty of
room for it to be accommodated within the left and right margins:

%===
\version "2.16.0"

#(set-global-staff-size 33)

\paper { #(set-paper-size "a4") }

\header {
title = "Preludio"
composer = "Jean-Baptiste Bésard (c.1567–1617)"
}

\relative c' { \repeat unfold 40 { c4 } }
%===

Nick
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Search in 2.16 docs returns results for 2.15 docs

[Nick Payne]

Example: from page
http://lilypond.org/doc/v2.16/Documentation/notation/index.html, enter
Dynamics in the search box. On the search results page, I can see that
the search command passed to Google is:

site:lilypond.org/doc/v2.15 Dynamics

and the results returned are from the 2.15 docs.

Nick


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Bad unicode char value in error message

[Nick Payne]

See below. Trying to use the unicode character value for a two-em dash
gives an error message where the char value has been incremented by
0x1000:

%==
\version "2.17.0"

\relative c' {
  c1^\markup { \char ##x2E3A }
}
%==


Processing `/home/nick/lilypond/examples/test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
programming error: FT_Get_Glyph_Name () error: invalid argument
continuing, cross fingers
programming error: Glyph has no name, but font supports glyph naming.
Skipping glyph U+10002E3A, file /home/nick/.fonts/CenturySchL-Roma.otf
continuing, cross fingers

 Original Message 
Subject:Re: Glissando between single notes in chord
Date:   Mon, 08 Oct 2012 16:53:52 +1100
From:   Nick Payne 
To: Werner LEMBERG 
CC: david.nales...@gmail.com, lilypond-u...@gnu.org



On 08/10/12 15:16, Werner LEMBERG wrote:
>> programming error: Glyph has no name, but font supports glyph naming.
>> Skipping glyph U+10002E3A, file
>> /usr/local/lilypond/usr/share/lilypond/current/fonts/otf/emmentaler-18.otf
> Uh, oh, this is a nonsense error message.  There *never* exists
> U+10002E3A, since this is outside of the valid Unicode range.
>
> Can you prepare a minimum example which delivers this error?

This gives an error message with the identical glyph number of U+10002E3A:

\version "2.17.0"

\relative c' {
  c1^\markup { \char ##x2E3A }
}




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering problems 2.17.4

[Nick Payne]

See example below:

a) without any fingering orientation specified, the fingerings are
incorrectly placed, such that the two fingerings above the staff
collide, and the fingerings also appear in the wrong order (the 0 should
not appear next to the E and the 2 should not appear above).

b) with fingering set to be on the left, the fingerings in the treble
voice are spaced slightly away from each other, causing a collision
between the 0 on the G and the 2 on the E.

\version "2.17.4"

\relative c'' {
  <<
{
  2
}
\\
{
  
}
  >>
  <<
{
  \set fingeringOrientations = #'(left)
  2
}
\\
{
  \set fingeringOrientations = #'(left)
  
}
  >>
}

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering problems 2.17.4

[Nick Payne]

On 11/10/12 08:02, Marek Klein wrote:
> Hello,
> 2012/10/10 Nick Payne  <mailto:nick.pa...@internode.on.net>>
>
> See example below:
>
> a) without any fingering orientation specified, the fingerings are
> incorrectly placed, such that the two fingerings above the staff
> collide, and the fingerings also appear in the wrong order (the 0
> should
> not appear next to the E and the 2 should not appear above).
>
> b) with fingering set to be on the left, the fingerings in the treble
> voice are spaced slightly away from each other, causing a collision
> between the 0 on the G and the 2 on the E.
>
>
> Thank you for the report, this has been added as
> http://code.google.com/p/lilypond/issues/detail?id=2890

p.s. problem (a) is not a regression from 2.16, but problem (b) is.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering problems 2.17.4

[Nick Payne]

On 11/10/12 13:18, Nick Payne wrote:
> On 11/10/12 08:02, Marek Klein wrote:
>> Hello,
>> 2012/10/10 Nick Payne > <mailto:nick.pa...@internode.on.net>>
>>
>> See example below:
>>
>> a) without any fingering orientation specified, the fingerings are
>> incorrectly placed, such that the two fingerings above the staff
>> collide, and the fingerings also appear in the wrong order (the 0
>> should
>> not appear next to the E and the 2 should not appear above).
>>
>> b) with fingering set to be on the left, the fingerings in the treble
>> voice are spaced slightly away from each other, causing a collision
>> between the 0 on the G and the 2 on the E.
>>
>>
>> Thank you for the report, this has been added as
>> http://code.google.com/p/lilypond/issues/detail?id=2890
>
> p.s. problem (a) is not a regression from 2.16, but problem (b) is.

Looking at the bug list, it seems that the fix for
https://code.google.com/p/lilypond/issues/detail?id=2764 may be the
cause of the second problem, causing the fingering from the different
voices to overlap when placed on the left.

Nick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Manual search returns results from wrong version

[Nick Payne]

Going to the manual page for 2.16 ( http://lilypond.org/manuals.html)
and entering a search term (eg I tried "footnote") in the search box at
upper right returns hits in the 2.17 manuals. The search presented to
Google is:

site:lilypond.org/doc/v2.17 footnote

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Manual search returns results from wrong version

[Nick Payne]

On 16/10/12 09:50, Nick Payne wrote:
> Going to the manual page for 2.16 ( http://lilypond.org/manuals.html)
> and entering a search term (eg I tried "footnote") in the search box
> at upper right returns hits in the 2.17 manuals. The search presented
> to Google is:
>
> site:lilypond.org/doc/v2.17 footnote
>
A similar problem but slightly different happens when searching within a
manual. For example, go to the 2.16 learning manual at
http://lilypond.org/doc/v2.16/Documentation/learning/index and enter a
search term in the search box at left below the table of contents. The
search passed to Google is actually for the 2.15 docs, and moreover is a
search of all the manuals and not just the learning manual:

site:lilypond.org/doc/v2.15 footnote

The original problem is in the bug list here:
http://code.google.com/p/lilypond/issues/detail?id=2909

Nick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Glissando avoid accidental bug?

[Nick Payne]

Regardless of whether I set the end-on-accidental override to true or
false, or omit it completely, the glissandi don't stop short of the
accidental.

\version "2.17.5"

\relative c'' {
  \accidentalStyle "modern"
  \override Glissando #'(bound-details right end-on-accidental) = ##t
  c1\glissando cis\glissando c
}


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

lyqi link from LP web site not valid

[Nick Payne]

The link to lyqi at 
http://lilypond.org/doc/v2.17/Documentation/web/easier-editing is not 
valid (the page http://nicolas.sceaux.free.fr/lilypond/lyqi.html doesn't 
exist. The correct link now appears to be http://github.com/nsceaux/lyqi 
.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Enhancement request - lookup of sub-properties

[Nick Payne]

See comment 13 of issue 3056: 
http://code.google.com/p/lilypond/issues/detail?id=3056. At the moment, 
when constructing an event function for a text spanner, one can't rely 
on using ^ or _ to set the direction of the spanner if one wants to 
tweak bound-details.right.text according to the direction, as that 
sub-property is not looked up - the direction has to be passed as an 
additional parameter - see comment 7 as an example of doing that.


Nick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering output change 2.17.9 -> 2.17.10

[Nick Payne]

To indicate guide fingering I've been using the code below. In 2.17.10, 
the fingering with guide is placed above the stem even though 
Fingering.add-stem-support = ##f. In 2.17.9 and earlier it was placed at 
the same height as normal fingering. I've attached pngs of the output on 
2.17.9 and 2.17.10:


\version "2.17.9"

% left-hand finger guide finger between notes
#(define (gx slope character fingering)
  ;; Purpose
  ;;   add ornamentation character before fingering symbol
  ;; Parameters
  ;;   slope : angle of rotation around right centre
  ;;   character : ornamentation character for fingering
  ;;   fingering : fingering designation for note
  ;; Examples
  ;;   (gx 0 #x2013 fingering)
  ;;   unicode #x2011 <-> #x2015 are different length "-" punctuation
  (let ((music (make-music 'FingeringEvent)))
(set! (ly:music-property music 'tweaks)
  (acons 'stencil
(lambda (grob)
  (let* ((finger (ly:music-property fingering 'digit))
(finger-stil (grob-interpret-markup grob (number->string 
finger)))

(finger-stil-ext (ly:stencil-extent finger-stil X))
(guide-char character)
(guide-stil (grob-interpret-markup grob (markup #:char 
guide-char)))
;; first combine stencils without any rotation of the guide 
line in
;; order to get X and Y extent to use for final translation 
of the
;; combined stencil so that the fingering number is 
correctly aligned

(stil
 (ly:stencil-combine-at-edge
  guide-stil
  X 1   ;; combine stencils along X-axis on right
  finger-stil
  0.3)) ;; add padding to move guide slightly left from 
finger number

(stil-ext-X (ly:stencil-extent stil X))
(stil-ext-Y (ly:stencil-extent stil Y))
;; now combine again with requested rotation
(stil
 (ly:stencil-combine-at-edge
  (ly:stencil-rotate guide-stil slope 1 0) ;; rotate 
"slope" around right centre

  X 1   ;; combine stencils along X-axis on right
  finger-stil
  0.3)) ;; add padding to move guide slightly left from 
finger number

;; Alter X-extents of combined stencil so that it
;; will be positioned with the number centered
;; over the note.
(adj-stil
 ;; leave fingerings oriented to side alone
 (if (= 0 (ly:grob-property grob 'side-axis))
stil
(ly:make-stencil
(ly:stencil-expr stil)
(coord-translate
  stil-ext-X
  (* 0.52 (- (cdr stil-ext-X) (interval-length 
finger-stil-ext

 stil-ext-Y
adj-stil))
  (ly:music-property music 'tweaks)))
 music))

% guide hyphen
%   4  c4^\ghy #45 ^2  c4-\ghy #-15 -3 c4_\ghy# -14 _4
ghy = #(define-music-function (parser location slope fingering) (number? 
ly:music?)

   (gx slope #x2010 fingering))

\relative c'{
\override Fingering.staff-padding = #'()
\override Fingering.add-stem-support = ##f
  4  
}
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

2.17 example for changing entire document fonts swells noteheads and other elements

[Nick Payne]

If I use the define fonts example in the documentation at 
http://lilypond.org/doc/v2.17/Documentation/notation/fonts#entire-document-fonts 
to change the document fonts, the noteheads swell so that they no longer 
fit between the staff lines. Have a look at the PDF output for the 
example below at magnification. The noteheads overlap the staff lines. 
Other notational elements are affected as well - the loop of the treble 
clef no longer sits on the bottom staff line but goes below it, and the 
time signature no longer fits between staff lines. Without the define 
fonts in the paper block, all these elements are the correct size. I 
tried a few different fonts for the serif, sans, and monospaced 
typefaces, and the behaviour was the same for all. If I use the example 
from the 2.16 docs for changing document fonts, i.e.


\paper  {
  myStaffSize = #20
  #(define fonts
(make-pango-font-tree "Times New Roman"
  "Nimbus Sans"
  "Luxi Mono"
  (/ myStaffSize 20)))
}

then the problem doesn't happen.

%===
\version "2.17.10"

\paper {
  #(define fonts
(make-pango-font-tree "Times New Roman"
  "Nimbus Sans"
  "Luxi Mono"
  (/ (* staff-height pt) 2)))
}

\relative c'{
c d e f g a b c
}
%===
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: 2.17 example for changing entire document fonts swellsnoteheadsand other elements

[Nick Payne]

On 14/01/13 23:34, Trevor Daniels wrote:

Trevor Daniels wrote Monday, January 14, 2013 12:17 PM

Nick Payne wrote Monday, January 14, 2013 7:46 AM


If I use the define fonts example in the documentation at
http://lilypond.org/doc/v2.17/Documentation/notation/fonts#entire-document-fonts
to change the document fonts, the noteheads swell so that they no longer
fit between the staff lines.

You're right Nick.  Looks like my 'fix' is not acceptable.  I'll
investigate further.


It looks like I was careless in setting the scaling factor to 2.
It should be 2.5, I think.

Nick: could you please check and see if this fixes your problem:

\paper {
#(define fonts
  (make-pango-font-tree "Times New Roman"
"Nimbus Sans"
"Luxi Mono"
(/ (* staff-height pt) 2.5)))
}


Yes, with the scaling factor set to 2.5 the problem is fixed.

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Positioning of "8" under clef symbol in G_8 clef

[Nick Payne]

The default positioning of the small "8" under the clef symbol when 
using the treble_8 or G_8 clef is too far to the right. It looks better 
when the X-offset is about 0.7 staff units:


%
\version "2.17.10"

\relative c'{
  \clef "G_8"
  \override Staff.OctavateEight.X-offset = #0.7
  c d e f
}
%

Nick
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Positioning of "8" under clef symbol in G_8 clef

[Nick Payne]

On 23/01/13 21:34, Colin Hall wrote:

Phil Holmes writes:


"Nick Payne"  wrote in message
news:50f5cf3f.9050...@internode.on.net...

The default positioning of the small "8" under the clef symbol when
using the treble_8 or G_8 clef is too far to the right. It looks better
when the X-offset is about 0.7 staff units:

%
\version "2.17.10"

\relative c'{
   \clef "G_8"
   \override Staff.OctavateEight.X-offset = #0.7
   c d e f
}
%

Nick


I'd guess that this is because the centre lines of the 8 and clef line up.
Do you have examples supporting your view?

Nick Payne posted to the lilypond-user thread here:

http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00927.html

commenting that there isn't a single value for X-offset that works for
all ottavations.
Here are a couple of scanned examples of clefs from commercial guitar 
scores, showing the 8 centred under the loop of the clef, and a couple 
of pngs showing Lilyponds default output and the output with the 
X-offset hard coded to 0.7, which better matches the alignment in the 
commercial scores.


Nick
<><><><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Positioning of "8" under clef symbol in G_8 clef

[Nick Payne]

On 24/01/13 17:29, m...@mikesolomon.org wrote:

On 23 janv. 2013, at 20:51, Nick Payne  wrote:


On 23/01/13 21:34, Colin Hall wrote:

Phil Holmes writes:


"Nick Payne"  wrote in message
news:50f5cf3f.9050...@internode.on.net...

The default positioning of the small "8" under the clef symbol when
using the treble_8 or G_8 clef is too far to the right. It looks better
when the X-offset is about 0.7 staff units:

%
\version "2.17.10"

\relative c'{
   \clef "G_8"
   \override Staff.OctavateEight.X-offset = #0.7
   c d e f
}
%

Nick

I'd guess that this is because the centre lines of the 8 and clef line up.
Do you have examples supporting your view?

Nick Payne posted to the lilypond-user thread here:

http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00927.html

commenting that there isn't a single value for X-offset that works for
all ottavations.

Here are a couple of scanned examples of clefs from commercial guitar scores, 
showing the 8 centred under the loop of the clef, and a couple of pngs showing 
Lilyponds default output and the output with the X-offset hard coded to 0.7, 
which better matches the alignment in the commercial scores.

Nick

I'm all for changing it - let me know if you need a patch to be proposed.

Cheers,
MS



Thanks. That would be good if it could be done.

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering with guide indications difference 2.16.2 -> 2.17.11

[Nick Payne]

The code below (I think it might have come from David Nalesnik) builds 
without any error on both 2.16.2 and 2.17.11, but the output is correct 
on 2.16.2 and incorrect on 2.17.11. On 2.17.11, the fingerings with 
guide indication that are to the left become centred on the note - on 
2.16 they stay in the correct position to the left. Is this difference 
anything to do with the fingering changes that were introduced earlier 
in 2.17?


Nick
\version "2.16.2"

% left-hand finger guide finger between notes
#(define (gx slope character fingering)
  ;; Purpose
  ;;   add ornamentation character before fingering symbol
  ;; Parameters
  ;;   slope : angle of rotation around right centre
  ;;   character : ornamentation character for fingering
  ;;   fingering : fingering designation for note
  ;; Examples
  ;;   (gx 0 #x2013 fingering)
  ;;   unicode #x2011 <-> #x2015 are different length "-" punctuation
  (let ((music (make-music 'FingeringEvent)))
(set! (ly:music-property music 'tweaks)
  (acons 'stencil
 (lambda (grob)
   (let* ((finger (ly:music-property fingering 'digit))
  (finger-stil (grob-interpret-markup grob (number->string finger)))
  (finger-stil-ext (ly:stencil-extent finger-stil X))
  (guide-char character)
  (guide-stil (grob-interpret-markup grob (markup #:char guide-char)))
  (stil
(ly:stencil-combine-at-edge
  (ly:stencil-rotate guide-stil slope 1 0) ;; rotate "slope" around right centre
  X 1   ;; combine stencils along X-axis on right
  finger-stil
  0.2)) ;; add padding to move guide slightly left from finger number
  (stil-ext-X (ly:stencil-extent stil X))
  (stil-ext-Y (ly:stencil-extent stil Y))
  ;; Alter X-extents of combined stencil so that it
  ;; will be positioned with the number centered
  ;; over the note.
  (adj-stil
;; leave fingerings oriented to side alone
(if (= 0 (ly:grob-property grob 'side-axis))
stil
(ly:make-stencil
  (ly:stencil-expr stil)
(coord-translate
  stil-ext-X
  (* 0.5 (- (cdr stil-ext-X) (interval-length finger-stil-ext
stil-ext-Y
   adj-stil))
 (ly:music-property music 'tweaks)))
music))

% guide-neutral
%   4  c4^\gn^2  c4-\gn-3  c4_\gn_4
gn = #(define-music-function (parser location fingering) (ly:music?)
   (gx 0 #x2013 fingering))
% guide-down
%   4  c4^\gd^2  c4-\gd-3  c4_\gd_4
gd = #(define-music-function (parser location fingering) (ly:music?)
   (gx 20 #x2013 fingering))
% guide-up
%   4  c4^\gu^2  c4-\gu-3  c4_\gu_4
gu = #(define-music-function (parser location fingering) (ly:music?)
   (gx -20 #x2013 fingering))
% guide slope
%   4  c4^\gsl #45 ^2  c4-\gsl #-15 -3  c4_\gsl# -14 _4
gsl = #(define-music-function (parser location slope fingering) (number? ly:music?)
   (gx slope #x2013 fingering))
% guide slope unicode
%   4  c4^\gsl #45 ##x2012 ^2  c4-\gsl #-15 ##x2013 -3  c4_\gsl #-14 ##x2014 _4
gsn = #(define-music-function (parser location slope unicode fingering) (number? number? ly:music?)
(gx slope unicode fingering))
% guide slope character
%   4  c4^\gsl #45 ##\+ ^2  c4-\gsl #-15 ##\! -3  c4_\gsl #-14 ##\! _4
gsc = #(define-music-function (parser location slope character fingering) (number? char? ly:music?)
(gx slope (char->integer character) fingering))

\relative c'' {
  2  |
  2  |
  \set fingeringOrientations = #'(left)
  2  |
}

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering output change 2.17.9 -> 2.17.10

[Nick Payne]

On 16/02/13 23:17, Colin Hall wrote:

Nick Payne writes:


On 14/01/13 17:31, Keith OHara wrote:

Nick Payne  internode.on.net> writes:


To indicate guide fingering I've been using the code below. In 2.17.10,
the fingering with guide is placed above the stem even though
Fingering.add-stem-support = ##f. In 2.17.9 and earlier it was placed at
the same height as normal fingering.

Mike changed the fingering placement  so that they go as close as they fit,
for issue <http://code.google.com/p/lilypond/issues/detail?id=2764>

It looks like your custom fingering stencil has a faked (shifted) extent
so that it lines up as you wish.  The fingering will fit, but its faked
extent interferes with the stem.  If I narrow the faked extent a bit, the
fingering slides down along the stem.

This hack seems to do the trick:


Nick, I'm cleaning up bug-lilypond unanswered reports, and found this
one from you.

I take it that you have succeeded in updating your scheme code to
deal with the change in fingering.

So, I'm deciding that there is no bug here, and I trust that you are ok with
that.


Yes, that particular problem was sorted, but see 
http://code.google.com/p/lilypond/issues/detail?id=3171, which is a 
different problem with the same code that only shows up on 2.17.


Nick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Problem with articulate and alternative

[Nick Payne]

Trying to build the example below with 2.17.13 gets this error in the 
console log:


Processing `/home/nick/lilypond/examples/test.ly'
Parsing.../usr/local/lilypond/usr/share/lilypond/current/ly/articulate.ly:446:13: 
In procedure map in expression (map (lambda # #)):
/usr/local/lilypond/usr/share/lilypond/current/ly/articulate.ly:446:13: 
Wrong number of arguments to #


If I remove the call to \articulate then there is no error, or if I 
leave the call to \articulate and remove the alternative block then 
there is no error.


%===
\version "2.17.13"

\include "articulate.ly"

notes = \relative c' {
  \repeat volta 2 { c c c c }
  \alternative {
{ c c c c }
{ d d d d }
  }
}

\score {
  \new Staff {
\notes
  }
}

\score {
  \new Staff {
\unfoldRepeats \articulate
\notes
  }
  \midi { }
}
%===

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Using \tupletSpan causing bad output

[Nick Payne]

See attached.

\version "2.17.13"

\relative c'' {
  \tupletSpan 8 \tuplet 3/2 { g8 fis e }
}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Using \tupletSpan causing bad output

[Nick Payne]

On 01/03/13 16:33, Nick Payne wrote:

See attached.

\version "2.17.13"

\relative c'' {
  \tupletSpan 8 \tuplet 3/2 { g8 fis e }
}


Forget about it. My bad. In the score where I encountered the output, I 
forgot that I had changed from tuplets using sixteenth notes to tuplets 
using eighth notes, and ignored the reason for the problem that was 
staring me in the face when condensing to a minimal example.



___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Ottava bracket in one voice

[Nick Payne]

I just encountered issue 1473 (ottavation marking in one voice affects 
all voices on the staff), and it took a bit of digging to find the 
solution (change Voice.middleCPosition in the other voices). Maybe there 
should be a short "Known issues and warnings" in the section of the NR 
dealing with ottava brackets - all the examples shown there are a single 
voice.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Ottava bracket in one voice

[Nick Payne]

On 04/03/13 20:24, Colin Hall wrote:

Nick Payne writes:


I just encountered issue 1473 (ottavation marking in one voice affects
all voices on the staff), and it took a bit of digging to find the
solution (change Voice.middleCPosition in the other voices). Maybe there
should be a short "Known issues and warnings" in the section of the NR
dealing with ottava brackets - all the examples shown there are a single
voice.

That sounds like a good idea, Nick. Would you mind drafting some
suitable text and sending it in?


Colin

Is the suggested text and example below clear or not? I grabbed the 
example notes from a question on the lilypond user list a couple of 
years ago, which seemed to demonstrate more clearly than anything else 
the problem and how to solve it: 
http://comments.gmane.org/gmane.comp.gnu.lilypond.general/61276. I guess 
that any work done on issue 1473 would affect this as well.


This is for a "Known issues and warnings" paragraph to be placed at the 
end of the subsection on ottava brackets in NR 1.1.3 Displaying Pitches.


"If you have more than one voice on the staff, setting ottavation in any 
voice will transpose the position of notes in all voices for the 
duration of the ottava bracket. If the ottavation is only intended to 
apply to that one voice, you can set the middleCPosition in the other 
voice(s) to stop them being transposed. For instance, in this example, 
set Voice.middleCPosition in the upper voice for the duration of the 
ottava bracket in the lower voice in order to prevent the tied chord in 
the upper voice from appearing an octave higher than it should. Note 
that the value you need to assign to middleCPosition will vary depending 
on the both the ottavation and clef being used.


\relative c {
  \clef bass
  <<
{
  1~
  \set Voice.middleCPosition = #6
  4
  \unset Voice.middleCPosition
}
\\
{ r2. \ottava #-1 4 4 \ottava #0 }
  >>
}

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering not aligned in 2.17, ok in 2.16

[Nick Payne]

See below. In 2.16.2, the fingering indications are vertically aligned. 
In 2.17.14, they aren't.


\relative f'' {
  \set fingeringOrientations = #'(left)
  4
}
<><>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering not aligned in 2.17, ok in 2.16

[Nick Payne]

On 23/03/13 00:31, Werner LEMBERG wrote:



See below. In 2.16.2, the fingering indications are vertically
aligned.  In 2.17.14, they aren't.

\relative f'' {
   \set fingeringOrientations = #'(left)
   4
}

Do you consider this a bug?  Actually, I like the new behaviour
better.  What does the literature say?


The great majority of commercial guitar scores I possess align the 
fingering vertically on chords, as 2.16 does.


Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fingering not aligned in 2.17, ok in 2.16

[Nick Payne]

On 24/03/13 04:07, Jan Nieuwenhuizen wrote:

Nick Payne writes:


Do you consider this a bug?  Actually, I like the new behaviour
better.  What does the literature say?

The great majority of commercial guitar scores I possess align the
fingering vertically on chords, as 2.16 does.

Which means that there is no strict agreement?  The great majority
have been wrong before.

What about the most beautiful scores amongst your collection, what do
they do?
I think the best look is achieved by either having the chord fingering 
aligned vertically, or having it so that it is spaced a consistent 
amount away from from the note or accidental - i.e. if fingering doesn't 
need to avoid an accidental elsewhere in the chord, it should sit where 
it would normally sit next to the notehead if the accidental wasn't 
there. The second option can be achieved in Lilypond by tweaking 
fingerings that don't need to avoid an accidental with a large negative 
script priority:


\relative f'' {
  \set fingeringOrientations = #'(left)
  4
  4
}
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

NR and allocating tweak command to variable

[Nick Payne]

I was trying to allocate a tweak command to a variable and eventually 
managed to get it to work after finding what I needed by a search of the 
lilypond-user archives ( 
http://lists.gnu.org/archive/html/lilypond-user/2011-09/msg00279.html).


However, I was initially misled by the NR having a section named "Using 
variables for tweaks ": 
http://www.lilypond.org/doc/v2.17/Documentation/learning/using-variables-for-tweaks, 
but this actually deals with using variables for overrides, and should 
maybe be renamed as "Using variables for overrides".


The code that I got to work is below:

\version "2.17.14"

fia = #(define-music-function
  (parser location grb)
  (ly:music?)
#{
  -\tweak script-priority #-199 -$grb
#})

\relative f'' {
  \set fingeringOrientations = #'(left)
  4
  4
  4
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Cross-voice arpeggio moves accidental away from notehead

[Nick Payne]

See example below. The chord across two voices has the accidental next 
to the notehead. Add an arpeggio and the accidental and arpeggio both 
get spaced away to the left. How do I move the accidental back next to 
the notehead?


\version "2.17.15"

\new Staff <<
  \set Staff.connectArpeggios = ##t
  \new Voice = "1" { \voiceOne \relative c'' { 2 s a,>\arpeggio } }
  \new Voice = "2" { \voiceTwo \relative c'' { 2 s cis,>\arpeggio } }

>>

\layout {
  \context {
\Staff \consists "Span_arpeggio_engraver"
  }
}

<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Changing fingering numerals

[Nick Payne]

If I override Fingering settings to change the style of the numerals 
used for fingering, as in the example below, I find that \finger inside 
a markup still uses the default fingering characters for the numerals.


Is this expected behaviour, or a bug? If expected behaviour, how can I 
change the fingering numerals for the trill to match those used on 
ordinary fingering?


%===
\version "2.17.20"

\relative f'' {
  \override Fingering.font-encoding = #'latin1
  \override Fingering.font-size = #-2
  \override Fingering.font-series = #'bold

f^\trill^\markup { \finger "4242" }
}
%===
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Problem using --doc option on install

[Nick Payne]

Using the --doc option on Lilypond install fails to download the doc 
tarball if a path is specified to the install file. i.e. On my system, 
if I run the install from the folder containing the file, the download 
of the doc tarball succeeds:


nick@nick-desktop ~/Downloads/lilypond $ sudo sh 
lilypond-2.18.0-1.linux-64.sh --doc


lilypond installer for version 2.18.0 release 1,
x86_64 build.
For a list of options, abort (^C) then do:
sh lilypond-2.18.0-1.linux-64.sh --help


You are about to install LilyPond in /usr/local/lilypond
A script in /usr/local/bin will be created as a shortcut.

Press ^C to abort, or Enter to proceed.

Making /usr/local/lilypond
Creating script /usr/local/bin/lilypond
Creating script /usr/local/bin/lilypond-wrapper.python
Creating script /usr/local/bin/lilypond-wrapper.guile
Creating script /usr/local/bin/uninstall-lilypond
Untarring lilypond-2.18.0-1.linux-64.sh
No ./lilypond-2.18.0-1.documentation.tar.bz2 found, downloading.
--2014-01-01 06:53:04-- 
http://lilypond.org/download/binaries/documentation/lilypond-2.18.0-1.documentation.tar.bz2

Resolving lilypond.org (lilypond.org)... 82.94.241.173
Connecting to lilypond.org (lilypond.org)|82.94.241.173|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 234535213 (224M) [application/x-tar]
Saving to: 'lilypond-2.18.0-1.documentation.tar.bz2’

0% [ ] 971,264 323KB/s


However, run the install from elsewhere with the path to the install sh 
specified, and the download of the doc tarball fails:


nick@nick-desktop ~ $ sudo sh 
~/Downloads/lilypond/lilypond-2.18.0-1.linux-64.sh --doc


lilypond installer for version 2.18.0 release 1,
x86_64 build.
For a list of options, abort (^C) then do:
sh /home/nick/Downloads/lilypond/lilypond-2.18.0-1.linux-64.sh --help


You are about to install LilyPond in /usr/local/lilypond
A script in /usr/local/bin will be created as a shortcut.

Press ^C to abort, or Enter to proceed.

Making /usr/local/lilypond
Creating script /usr/local/bin/lilypond
Creating script /usr/local/bin/lilypond-wrapper.python
Creating script /usr/local/bin/lilypond-wrapper.guile
Creating script /usr/local/bin/uninstall-lilypond
Untarring /home/nick/Downloads/lilypond/lilypond-2.18.0-1.linux-64.sh
No 
.//home/nick/Downloads/lilypond/lilypond-2.18.0-1.documentation.tar.bz2 
found, downloading.
--2013-12-31 21:33:33-- 
http://lilypond.org/download/binaries/documentation//home/nick/Downloads/lilypond/lilypond-2.18.0-1.documentation.tar.bz2

Resolving lilypond.org (lilypond.org)... 82.94.241.173
Connecting to lilypond.org (lilypond.org)|82.94.241.173|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-12-31 21:33:35 ERROR 404: Not Found.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Web site manual search defaulting to 2.17

[Nick Payne]

Using the search box at top right on the LP web site is searching the 
2.17 rather than the 2.18 manuals. e.g. The search submitted to google is:


https://www.google.com/search?btnG=Google+Search&brute_query=bar+engraver&q=site%3Alilypond.org%2Fdoc%2Fv2.17+bar+engraver

Shouldn't the default search be the current stable version?

Nick

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Web site manual search defaulting to 2.17

[Nick Payne]

On 23/01/2014 4:24 PM, Federico Bruni wrote:
2014/1/23 Nick Payne <mailto:nick.pa...@internode.on.net>>


Using the search box at top right on the LP web site is searching
the 2.17 rather than the 2.18 manuals. e.g. The search submitted
to google is:


https://www.google.com/search?btnG=Google+Search&brute_query=bar+engraver&q=site%3Alilypond.org%2Fdoc%2Fv2.17+bar+engraver

Shouldn't the default search be the current stable version?


There's an issue already:
https://code.google.com/p/lilypond/issues/detail?id=2909

I think that it's just a matter of waiting for google to reindex the 
pages.


No, it's not a matter of waiting for Google to reindex pages. The 
parameters being passed to Google search by the LP web site include 
site:lilypond.org/doc/2.17, which limits the search to the manuals for 2.17.


Nick
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Fw: Re[2]: coloring voices vs systemStartDelimiterHierarchy

[Nick Payne]

On 10/06/2015 07:02, musicus wrote:

Hi Klaus,

unfortunately I have to use \startStaff \stopStaff, because I want to 
set ossia variations above the original score.

I'll attach the complete score, so you can see my problem.


If I save the ly file and try to build it (Windows, Lilypond 2.19.21) it 
causes lilypond to terminate with the error below. I also loaded it into 
Frescobaldi and got the attached Mingw error msgbox:


>lilypond "d:\Users\Nick\lilypond\examples\Saraband coloring.ly"
GNU LilyPond 2.19.21
Processing `d:/Users/Nick/lilypond/examples/Saraband coloring.ly'
Parsing...
Interpreting music...[8][16][24]
Preprocessing graphical objects...Assertion failed!

Program: C:\Program Files (x86)\LilyPond\usr\bin\lilypond.exe
File: 
/home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.gi

t-release-unstable/lily/simple-spacer.cc, Line 251

Expression: fabs (configuration_length (cur_force) - cur_len) < 1e-6

This application has requested the Runtime to terminate it in an unusual 
way.

Please contact the application's support team for more information.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond