Re: Ski Emoji Error

[Jay Anderson]

On Tue, Apr 24, 2018 at 6:10 AM, James Lowe  wrote:
>
> > Probably depends on the Ghostscript version?  Looks fine here:
>
> Well it looks OK but I get the same 'error' with gs version 9.22 so I
> compiled and installed 9.23 and I no longer get this 'failed files' message.
>

I'm unable to download 2.19.81 (download links are broken). Does it include
a newer version of ghostscript?

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

Ski Emoji Error

[Jay Anderson]

Minimal Example:

=
\version "2.19.80"

\markup "⛷"
=

The end of the output from lilypond -V ski.ly:
=
Converting to `ski.pdf'...
Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
-dAutoRotatePages=/None -sOutputFile=ski.pdf -c.setpdfwrite
-f/tmp/lilypond-TAEKuY'...

GPL Ghostscript 9.21 (2017-03-16)
Copyright (C) 2017 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Error: /invalidfont in --glyphshow--
Operand stack:
   1.912   5.6906   -5.5524   uni26F7
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
 --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
 --nostringval--   false   1   %stopped_push   1983   1   3   %oparray_pop
 1982   1   3   %oparray_pop   1966   1   3   %oparray_pop   1852   1   3
 %oparray_pop   --nostringval--   %errorexec_pop   .runexec2
 --nostringval--   --nostringval--   --nostringval--   2   %stopped_push
 --nostringval--   0   --nostringval--   %repeat_continue   --nostringval--
Dictionary stack:
   --dict:1210/1684(ro)(G)--   --dict:0/20(G)--   --dict:108/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
Current file position is 1976481
GPL Ghostscript 9.21: Warning: 'loca' length 20 is greater than numGlyphs 1
in the font NotoSansSymbols.
GPL Ghostscript 9.21: Unrecoverable error, exit code 1
warning: `(gs -dSAFER -dDEVICEWIDTHPOINTS=595.28
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
-r1200 -sDEVICE=pdfwrite -dAutoRotatePages=/None -sOutputFile=ski.pdf
-c.setpdfwrite -f/tmp/lilypond-TAEKuY)' failed (256)

fatal error: failed files: "ski.ly"
=

Other emojis seem to work fine. What does the above error mean? If the font
doesn't include this emoji that's fine, but that isn't obvious from the
above.

Thanks.

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

Re: Mark / Barcheck Bug (#1626) Appearing Again

[Jay Anderson]

On Sat, Oct 15, 2016 at 6:38 PM, Andrew Bernard
<andrew.bern...@gmail.com> wrote:
> Don't you have to provide an argument for \mark, I thought?
>
> I am not familiar with 2.18.2, but in 2.19.48 you do:

Yep. I think \mark requiring an argument explains the errors in the
examples fully:
- The first error it saying that the argument you gave to \mark was wrong
- Lilypond kept trying to make sense of things and kept processing.
Since the argument to \mark was already used there is now 1 too few
beats in that measure.

I think lilypond is behaving as expected here. You might be trying to
do \mark \default or \mark "C" instead.

-Jay Anderson

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

Re: Hairpins not aligned/symmetrical

[Jay Anderson]

On Mon, Jul 21, 2014 at 1:39 PM, Janek Warchoł janek.lilyp...@gmail.com wrote:
 2014-07-21 22:15 GMT+02:00 Steven Weber pant...@hotmail.com:
 Try:

 \relative c' {
   f8.\ d16 g4.\ f8\!
 }

 Nevertheless, what Aliosha says is a valid feature request (it's not
 always desirable to have decrescendo right after crescendo, but they
 should still align).  I'd say this is related to
 https://code.google.com/p/lilypond/issues/detail?id=2459

This is the closest I've got (it should also work in 2.18 though I
haven't tested it):

\version 2.19.8

invisibleCresc = #(make-music 'CrescendoEvent 'span-direction START
'span-type 'text 'span-text  'tweaks '((dash-period . -1)))

\relative c' {
  f8.\ d16\invisibleCresc g4.\ f8\!
}

The hairpins align vertically, but it unfortunately causes the first
hairpin to end early. I'm sure there are a few more tweaks to make it
work.

-Jay

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

Re: 2.19.x Point and click references

[Jay Anderson]

On Sun, Apr 27, 2014 at 11:04 PM, David Kastrup d...@gnu.org wrote:
 When compiling the above files the point-and-click links do not point
 to the '00.ily' file. Instead they all point to the final line of
 'point_and_click_2.19.ly'. In 2.18 this worked correctly.

 Without actually testing it, I consider this unlikely.  It would appear
 to be URL:http://code.google.com/p/lilypond/issues/detail?id=3153,
 namely changed in 2.17.13.  While it's conceivable that \include
 handling has been changed independently, this does not really change the
 rationale of the change, namely pointing out _which_ invocation of a
 function is responsible for some input.  Which is particularly important
 for trivially correct functions called hundreds of times.  You really
 don't want to have point-and-click point to the function definition
 then.

You're absolutely right. I was misremembering. I should have tried this.

 it's also worth noting that if you introduce an error to 00.ily the
 errors reported do use the correct filename and line number.

 Yes, that's what one wants for debugging.

 There is a somewhat funny way to change this behavior: just use an
 argument name different from location for the location argument, and
 #{...#} will not be able to pick it up for passing it to
 point-and-click.

This is interesting. I changed the 'location' argument's name and it
still showed correct error locations. Also the point and click
locations are correct. So it seems a workaround is to do this
renaming. Thanks, this is useful (though somewhat surprising
behavior).

Also I think this explains why I thought it worked in the past. I
think I was using a pure scheme function in between the score
generation and the call from lilypond. So it just happened to work.

-Jay

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

2.19.x Point and click references

[Jay Anderson]

point_and_click_2.19.ly:
=
\version 2.19.5

makeScore =
#(define-void-function (parser location) ()
  (let ((score
 #{
   \score
   {
 \new Staff { \include 00.ily }
   }
 #}))
(add-score parser score)))

\makeScore
=

00.ily:
=
\relative c' { c4 c c c | }
=

When compiling the above files the point-and-click links do not point
to the '00.ily' file. Instead they all point to the final line of
'point_and_click_2.19.ly'. In 2.18 this worked correctly. it's also
worth noting that if you introduce an error to 00.ily the errors
reported do use the correct filename and line number.

-Jay

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

Slur padding on dotted notes

[Jay Anderson]

This is a nitpick, but it's noticeable.

\version 2.19.2 % and 2.18.0

\score {
  \new Staff \relative c''' {
%non-dotted
\time 4/4
g4( f) g( a) |
g4~ g a~ a |

%dotted
\time 12/8
g4.( f) g( a) | %Slurs pushed further away than necessary.
g4.~ g a~ a | %Ties look ok to me.
  }
}

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

Midi early start (2.19.2)

[Jay Anderson]

Removing the Dynamic_performer causes rests at the start of a piece to
be skipped causing misalignment with other voices. I've only tested
this with 2.19.2 and 2.18.0. It works correctly in 2.18.0.



\version 2.19.2 % Work in 2.18.0

\score
{
  
\new Staff \relative c' { R1*3 e1 e e | }
\new Staff \relative c { c1 c c c c c | }
  
  \midi
  {
\context
{
  \Voice
  \remove Dynamic_performer
}
  }
}

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

Re: \epsfile relative file locations

[Jay Anderson]

On Fri, Nov 29, 2013 at 5:43 PM, Eluze elu...@gmail.com wrote:
 thanks for this workaround - it works as expected.

As long as your command line is 'lilypond file.ly' and the eps file is
imported from file.ly. What's the correct way to get the name of the
current file? I looked for a little while, but couldn't figure it out.

 I think LilyPond should do this by default and if not the function shouldn't
 be named /relative/ (I get problems in my environment in windows)

Yeah sorry about that. It should be named something different. I
noticed that using 'relative' broke after I sent the report.

-Jay

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

\epsfile relative file locations

[Jay Anderson]

With the normal \include command and #(ly:set-option
'relative-includes #t) relative includes work. However \epsfile
doesn't follow relative includes. For instance if you have a.ly which
uses b.eps and compile it from a different directory (e.g. 'lilypond
../a.ly') it will fail.

Here's a workaround:

% Guile 1.8. This makes a bad assumption that filename is second option on the
% command line. It could be somewhere else or not on the command line at all if
% it is included from another file.
%
% What's the right way to do this? It looks like 2.0 has a (current-filename)
% function which might be a better option, but I'm not sure how that interacts
% with lilypond files.
#(define (relative filename)
  (string-append (dirname (cadr (command-line))) / filename))

... \epsfile #X #50 #(relative file.eps) ...

-Jay

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

Re: show-available-fonts output can't be piped

[Jay Anderson]

stderr.

$ lilypond -dshow-available-fonts 2 fonts.txt
$ lilypond -dshow-available-fonts 21 | less

-Jay

On Wed, Jul 10, 2013 at 10:26 PM, Mark Polesky markpole...@yahoo.com wrote:
 Am I overlooking something simple?  These don't do what I'd
 expect:

 $ lilypond -dshow-available-fonts | less
 $ lilypond -dshow-available-fonts  fonts.txt

 - Mark


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

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

Re: 2.17.16 vs 2.17.17 Page Breaking

[Jay Anderson]

On Sat, May 4, 2013 at 7:21 PM, Keith OHara k-ohara5...@oco.net wrote:
 I cannot reproduce the full problem.  Has anyone seen LilyPond print
 'annotate-spacing' output where both the limits for the top staff are
 negative numbers?

I figured out where this was coming from. I was using something like

\score  { label #'a } { ... music ...} 

This is a bad idea (*hangs head in shame*) and I've fixed it (moved
label before score). This specific piece is now back on one page. (I'm
not sure why it wasn't creating an empty staff though.) However others
are still spaced more widely (compared with 2.17.16). I haven't
investigated those yet. I'll try and figure out what's causing this
hopefully in a few days (sorry for my slow responses). Sorry for the
false positive.

 When the top staff ends at 0, the commit cited above gives generally better
 page-breaking estimates of the height of the staff (see
 http://code.google.com/p/lilypond/issues/detail?id=3342).  The estimate is
 a bit worse in the case where it allows space for a tempo that is completely
 hidden.  The reason given for hiding the tempo completely was that it is for
 midi only, but the manual says in that case to use  \midi {\tempo...}

This is true for the majority of cases I'm sure, but there are some
drawbacks. \midi { \tempo ... } is a one time thing. But I can put
\tempo commands throughout a piece for changes in tempo. It feels odd
to include only the initial tempo in the midi block. As an alternative
I could use tags or separate midi music sections for midi only items,
but that complicates things since sometimes I want the tempo visible
(\tempo Allegro 4=108). So while there are solutions I would still
expect 'tempoHideNote = ##t' to cause the tempo to take no space or to
issue a warning.

 I think I have an implementation of \markLenghtOn that will avoid this
 problem, but if we don't confirm that, then people setting score and parts
 will space the tempo marks in the parts by hand
 https://lists.gnu.org/archive/html/lilypond-devel/2013-02/msg00075.html

Yes, I think the tempo work you're doing is great (and will greatly
simplify some of my scores).

-Jay

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

Re: 2.17.16 vs 2.17.17 Page Breaking

[Jay Anderson]

On Wed, May 1, 2013 at 12:15 AM, Keith OHara k-ohara5...@oco.net wrote:
 Nothing was intended to change page-breaking between those versions.

 However, almost anything changing layout will change the page-breaking
 when pages are close to full.

 If one of these things puts the page-breaking back to the old way
   \markLengthOff
   \override Score.RehearsalMark #'Y-offset = 0
   \override Score.MetronomeMark #'Y-offset = 0
 then something in my change to give space to tempo marks has caused trouble.

(moving to the bug list)

Git bisect led to commit b6f94447415dded7c6e146b41b6139fe76cb84c4
(http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=b6f94447415dded7c6e146b41b6139fe76cb84c4).
I do have a '\tempo 4=108' in the score (for midi purposes), but it is
hidden with

\layout
{
  \context
  {
\Score
tempoHideNote = ##t
  }
}

When I take out the invisible tempo mark it is set on 1 page again. It
appears that a hidden tempo mark is affecting the spacing somehow. I
haven't had much success creating a minimal example yet unfortunately.
I can probably attempt again this weekend if needed. Thanks.

-Jay

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

Table of contents with multiple files

[Jay Anderson]

File 'toc_a.ly'
==
\version 2.17.14

\markuplist \table-of-contents
\pageBreak

\tocItem A
\markup A
\pageBreak

\tocItem B
\markup B
\pageBreak
==


File 'toc_b.ly'
==
\version 2.17.14

\markuplist \table-of-contents
\pageBreak

\tocItem C
\markup C
\pageBreak

\tocItem D
\markup D
\pageBreak
==

if you run 'lilypond toc_a.ly toc_b.ly' toc_b.pdf will end up with all
of the items from toc_a.ly in the table of contents (except with
question marks for the page number).

-Jay

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

Odd spacing with dynamics

[Jay Anderson]

\version 2.17.14

\paper
{
  tagline = ##f
}

filler = \repeat unfold 6 {c4 c c c | \noBreak}

\score
{
  \new Staff \relative c'
  {
c4 c c c | \noBreak
c c2 c8 c |
\filler
  }
}

\score
{
  \new Staff \relative c'
  {
c4 c c c | \noBreak

  {c c2 c8 c |}
  {s2\ s\ s1*0\!}

\filler
  }
}

In the second score above the half note is moved too close to the
eighth notes. This is a somewhat contrived example, but it looks worse
in a larger score I have on a line that gets a bit compressed.

I'm not sure if this is a known issue or not. What would be a good
workaround? Is there a way to make the spacing ignore the dynamics?
The best I've found so far is to align the dynamics with the rhythm:
c\ c2\ c8 c\!. Honestly, this is good enough, but the original
behavior surprised me.

Thanks.

-Jay

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

Re: Add tempo spanners

[Jay Anderson]

On Tue, Feb 12, 2013 at 5:43 PM, Colin Hall colingh...@gmail.com wrote:
 It would be great to have a TempoTextSpanner, for example in order to
 handle common notation such as

   rit. - - - - a tempo
 or
   rall - - - -

 I do not see this request tracked yet.

 Thanks for the report, Xavier, but I think we already have this feature
 in Lilypond, don't we? See:

If I'm understanding the request correctly this functionality isn't
currently available. Text spanners live in the staff.
TempoTextSpanners would live in the score and be set like current
tempo marks (bold and above the system). I've often wanted this
feature as well.

-Jay

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

Re: 2.16.0 and 2.16.1 change with #{ #} syntax

[Jay Anderson]

On Tue, Jan 15, 2013 at 2:14 AM, David Kastrup d...@gnu.org wrote:
 It is somewhat embarrassing, but in my local stable branch I had
 already collected a few of the file/parser/EOF-related fixes in 2.17
 when I told Philip to go ahead with releasing 2.16.2.  I suppose I
 should complete the collection and push it in time for the next release.

No worries. Thanks for taking care of this. I have options in the
meantime: 2.16.0 or 2.17.10.

-Jay

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

2.16.0 and 2.16.1 change with #{ #} syntax

[Jay Anderson]

In 2.16.0 creating a book inside #{ #} returned the book. In 2.16.1 and
2.16.2 this is no longer always the case. Here's an example which fails:


\version 2.16.2

makeBook =
#(define-void-function (parser location) ()
  (let ((the-book
#{
  \book
  {
\include header.ily
\score
{
  \new Staff
  {
c'1
  }
}
  }
#}))
(display the-book) ;;; in 2.16.2 #undefined
(newline)
(print-book-with-defaults parser the-book)))

\makeBook


header.ily just contains:

\header
{
}


If you take the \include out or put the header inline it compiles, but that
defeats the purpose.

I just tried 2.17.10 and the behavior is fixed there.

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

Cue Stem Alignment of Merged Noteheads

[Jay Anderson]

\version 2.16.0

mus = \relative c'
{
  c8 d e f g a b c
}

\score
{
  \new Staff
  
\new CueVoice
{
  \voiceOne
  % Workaround:
  %\override Stem #'X-offset = #1.22
  \mus
}
\new Voice
{
  \voiceTwo
  \mus
}
  
}

The cue stems look like they're coming out of the middle of the shared
notehead. It's easy to manually push the stems over (in practice this needs
to be done on a note-by-note basis), but it'd be nice if this happened
automatically.

Thanks.

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

Dash span bars broken with alignAboveContext

[Jay Anderson]

\version 2.15.41

mus = \repeat unfold 5 c'1

\score
{
  \new StaffGroup \with
  { \override SpanBar #'glyph-name = #dashed }
  
\new Staff=x
{
  \mus
  
\mus
\new Staff \with { alignAboveContext = x } \mus
  
}
  
}

This example works in 2.14.2 with dash bars being between the staves.
In 2.15.41 the dashes are missing. Taking out the alignAboveContext
make dashed bars show, but the staff is below x.

-Jay

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

Tuplet numbers placed incorrectly

[Jay Anderson]

\version 2.15.33

\paper { ragged-right = ##t }

\score
{
  \new Staff \relative c'
  {
R1 | \break
\times 2/3 {e8(- a e)}
  }
}

In this example the tuplet number is placed within the staff. Taking
out the break, the accent, or the slur causes the tuplet to be placed
correctly. I haven't done a rigorous search for the cause. I know that
at least 2.15.23 renders this example correctly and 2.15.24 does not.
I couldn't find an issue already opened for this. Thanks!

-Jay

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

Re: Abrupt end of interpreting music (segmentation fault)

[Jay Anderson]

On Sun, Feb 19, 2012 at 8:32 AM, Phil Holmes m...@philholmes.net wrote:
 I don't normally install LilyPond on my Linux box - I simply run a
 self-compiled version.  It's 64-bit Ubuntu and on this, your file compiles
 and runs fine.  So I'm assuming (if you know better, please say) that this
 is unlikely to be generic 64-bit, but Debian 64-bit specific.  We'll
 certainly pick it up as a bug, but it's likely to be hard to fix, bearing in
 mind the fact that our standard development environment is Ubuntu.

I also run a 64-bit Ubuntu (11.10, Linux 3.0.0-15-generic) box and
this example segfaults on an installed 2.15.30, but not on lilypond
built from master. So perhaps this bug was somehow fixed? Every once
in a while I get segfaults on 64-bit related to the
Span_bar_stub_engraver (I tracked it down to the specific commit at
one point: 
http://lists.gnu.org/archive/html/lilypond-devel/2012-01/msg00201.html).
Adding this into the top of the attached example avoids the segfault
in 2.15.30:

\layout
{
  \context
  {
\PianoStaff
\remove Span_bar_stub_engraver
  }
}

In my case I had a dynamic section which I hadn't filled in yet. I
haven't looked at this example too much in depth, but it seems similar
enough that the same workaround fixed it.

-Jay

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

Endless Loop

[Jay Anderson]

Compiling this score (reduced from a larger score) never terminates:
=
\version 2.15.30

\score
{
  \new Staff \relative c'
  {
R1 |
\stopStaff
R1 | r2
  }
}
=

If I'm stopping the staff I should probably be using spacer rests
instead and this problem goes away. So I finally figured that out, but
I would expect some sort of warning or error instead of an infinite
loop.

I traced this to this commit:
=
$ git bisect bad
3d8f4559228bd8a4a30bb024163b64d425b76f18 is the first bad commit
commit 3d8f4559228bd8a4a30bb024163b64d425b76f18
Author: Benkő Pál benko@gmail.com
Date:   Mon Feb 13 18:49:17 2012 +0100

Issue 2300: do not tinker with the position of a pitched rest
=

It seems to be stuck in this loop (rest.cc, line 78):

  /*
make sure rest is aligned to a staff line
  */
  while (!Staff_symbol_referencer::on_line (me, pos))
++pos;

-Jay

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

Beam Collides with Clef Number

[Jay Anderson]

\version 2.15.28

\score
{
  \new Staff \relative c''
  {
\clef treble
c8^[
\clef bass^8
e,]
  }
}

I'm pretty sure this is an OctavateEight created with the clef. Is
there a way to tell the beam to avoid it without code changes?

-Jay
attachment: beam_over_clef_test.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Tuplet Bracket Spacing Bug

[Jay Anderson]

\version 2.15.26

\score
{
  \new Staff \relative c''
  {
\times 2/3 {c4\ff c c}
  }
}

It looks like the bracket is making space for the dynamic, but the
dynamic is staying outside anyway. The same effect happens with beamed
tuplets, but in that case there's no bracket to move. It was
introduced sometime between 2.15.23 and 2.15.24 (I haven't narrowed it
down to the commit).

-Jay
attachment: tuplet_bug.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Segfault 2.15.23 Span_bar_stub_engraver

[Jay Anderson]

I've been unable to create a good small example so far. When I take
out seemingly unrelated sections it compiles which makes it difficult
to narrow down. Removing the Span_bar_stub_engraver from my
PianoStaff fixes the segfault, but what won't work if I do this?

Below is at least the stack trace in case there is something obvious.
This stack was made with a build using the latest on master this
morning. Thanks for the help!

-Jay

#0  Scheme_hash_table::try_retrieve (this=0x0, k=0x7342f520,
v=0x7fff8b78) at scm-hash.cc:97
#1  0x0048e331 in Context::where_defined (this=0xd71ff0,
sym=0x7342f520, value=0x7fff8b78) at context.cc:420
#2  0x004953a7 in updated_grob_properties (tg=optimized out,
sym=0x7342f520) at context-property.cc:264
#3  0x006272fe in Span_bar_stub_engraver::process_acknowledged (
this=0xce1d10) at span-bar-stub-engraver.cc:119
#4  0x00685018 in invoke (this=optimized out)
at ./include/translator-group.hh:46
#5  Translator_group::precomputed_translator_foreach (this=optimized out,
idx=optimized out) at translator-group.cc:325
#6  0x004b1975 in Engraver_group::do_announces (this=0x109dd90)
at engraver-group.cc:174
#7  0x004b1942 in Engraver_group::do_announces (this=0xcc31a0)
at engraver-group.cc:169
#8  0x005ddcfd in one_time_step (this=0xcc31a0)
at score-engraver.cc:152
#9  Score_engraver::one_time_step_callback (self=0xcc31a0, ev=optimized out)
at score-engraver.cc:145
#10 0x0051c4cd in Listener::listen (this=optimized out,
ev=optimized out) at listener.cc:44
#11 0x004a05cf in Dispatcher::dispatch (this=0xc41260,
sev=optimized out) at dispatcher.cc:152
#12 0x0049ef8d in Dispatcher::broadcast (this=optimized out,
ev=optimized out) at dispatcher.cc:178
#13 0x0048e7ca in Context::internal_send_stream_event (this=0xf8c268,
type=optimized out, origin=0x0, props=0x7fff9060) at context.cc:460
#14 0x004d6cde in Global_context::run_iterator_on_me (this=0xf8c1e0,
iter=0xdf2e30) at global-context.cc:169
#15 0x004d8c4b in ly_interpret_music_expression (mus=optimized out,
ctx=0x70d94d30) at global-context-scheme.cc:119
#16 0x004d93d1 in ly_run_translator (mus=0x7fffef54c620,
output_def=optimized out) at global-context-scheme.cc:146
#17 0x005dcf00 in Score::book_rendering (this=0xaf4ef0,
layoutbook=0xdb3150, default_def=0xc29f50) at score.cc:155
#18 0x0045e324 in Book::process_score (this=optimized out,
s=optimized out, output_paper_book=0xce27a0, layout=optimized out)
at book.cc:236
#19 0x0045e561 in Book::process (this=0xc241d0,
default_paper=optimized out, default_layout=0xc29f50, parent_part=0x0)
at book.cc:302
#20 0x0045e71b in Book::process (this=optimized out,
default_paper=optimized out, default_layout=optimized out)
at book.cc:207
#21 0x0045f013 in ly_book_process (book_smob=0x702766d0,
default_paper=0x703c0aa0, default_layout=0x705b47a0,
output=0x73568b60) at book-scheme.cc:76
#22 0x77b2bdcf in scm_dapply () from /usr/lib/libguile.so.17
#23 0x77b2d4cb in ?? () from /usr/lib/libguile.so.17
#24 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
#25 0x006adf6d in yyparse (parser=0x9dbda0) at parser.yy:592
#26 0x006b5959 in Lily_parser::do_yyparse (this=optimized out)
at parser.yy:3178
#27 0x0050ed7b in Lily_parser::parse_file (this=0x9dbda0, init=...,
name=optimized out, out_name=optimized out) at lily-parser.cc:124
#28 0x00514b11 in ly_parse_file (name=optimized out)
at lily-parser-scheme.cc:121
#29 0x77b2d816 in ?? () from /usr/lib/libguile.so.17
#30 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
#31 0x77b84903 in scm_c_catch () from /usr/lib/libguile.so.17
#32 0x77b84b0e in scm_catch_with_pre_unwind_handler ()
   from /usr/lib/libguile.so.17
#33 0x77b2bdcf in scm_dapply () from /usr/lib/libguile.so.17
#34 0x77b2d4cb in ?? () from /usr/lib/libguile.so.17
#35 0x77b2cb0c in ?? () from /usr/lib/libguile.so.17
#36 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
#37 0x721c9fd1 in scm_srfi1_for_each ()
   from /usr/lib/libguile-srfi-srfi-1-v-3.so
#38 0x77b2d6aa in ?? () from /usr/lib/libguile.so.17
#39 0x77b2cb0c in ?? () from /usr/lib/libguile.so.17
#40 0x77b2d343 in ?? () from /usr/lib/libguile.so.17
#41 0x77b2be77 in scm_dapply () from /usr/lib/libguile.so.17
#42 0x005268d2 in main_with_guile () at main.cc:440
#43 0x77b475cf in ?? () from /usr/lib/libguile.so.17
#44 0x77b1e16a in ?? () from /usr/lib/libguile.so.17
#45 0x77b84903 in scm_c_catch () from /usr/lib/libguile.so.17
#46 0x77b1e6f7 in scm_i_with_continuation_barrier ()
   from /usr/lib/libguile.so.17
#47 

Paper block ordering

[Jay Anderson]

In 2.15.19 the ordering of things in the paper block matters where it
didn't before. An example which removes the first system indent:


\version 2.15.19

\paper
{
  indent = 0\in
  #(set-paper-size letter)
  %indent = 0\in %Move the indent here to have the indent take effect.
}

\score { \new Staff {R1} }


This is a very minor issue (if it is an issue rather than a design
decision going forward), but I figured that it's worth mentioning.

-Jay

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

Add 6x9 Paper Size

[Jay Anderson]

6 x 9 in. isn't currently available. I haven't found a standard name
for this size. Lulu calls it 'US Trade',
http://en.wikipedia.org/wiki/Book_size calls it 'octavo'. In any case
it seems to be a fairly common size that would be useful to add (and
custom sizes are clunky to add and maintain - is there a better way
besides modifying paper.scm?). My recommendation to add to paper.scm:

(6x9 . (cons (* 6 in) (* 9 in)))

Thanks.

-Jay

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

Re: Add 6x9 Paper Size

[Jay Anderson]

On Fri, Sep 30, 2011 at 10:47 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
 On Sep 30, 2011, at 7:43 PM, Peekay Ex wrote:
 http://code.google.com/p/lilypond/issues/detail?id=1949

Thanks

 #(set! paper-alist (cons '(6x9 cons (* 6 in) (* 9 in)) paper-alist))
 #(set-default-paper-size 6x9)

 Is a workaround that you can use without modifying paper.scm.  But, of 
 course, there's nothing wrong with modifying paper.scm!

Modifying paper.scm is annoying when installing a new version of
lilypond (Even though that's the recommended workaround in 4.1.2 of
the notation reference). Thanks for the workaround.

Here's what I ended up doing:

#(define (add-paper-size paper-def)
  (set! paper-alist (cons paper-def paper-alist)))
#(define (set-custom-paper-size paper-def)
  (add-paper-size paper-def)
  (set-paper-size (car paper-def)))

\paper
{
  #(set-custom-paper-size '(6x9 . (cons (* 6 in) (* 9 in
}

-Jay

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

Lyrics alignment to notes

[Jay Anderson]

\version 2.14.2

words = \lyricmode
{
  %Uncomment this to delay alignment of new lyrics by one note.
  %\set stanza = 1.
  
{ a b c d }
\new Lyrics \lyricsto melody
{ a b c d }
  
}

melody = \relative c' { c c c c }

\score
{
  
\new Staff \new Voice=melody \melody
\new Lyrics \lyricsto melody \words
  
}

Is this the same as bug 333?
(http://code.google.com/p/lilypond/issues/detail?id=333)
I think it probably is since I just discovered that same workaround of
moving the \set stanza = 1. inside the first section corrects the
issue. Anyway I'll send this anyway in case some else is searching for
a workaround to the same issue.

Thanks!

-Jay

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

AmbitusAccidental avoid-slur not set?

[Jay Anderson]

\version 2.14.1

\score {
  \new Score {
\new Voice \with {\consists Ambitus_engraver} {
  cis4( ees)
}
  }
}


This results in this warning:
warning: Ignoring grob for slur: AmbitusAccidental. avoid-slur not set?

This may be more of a feature request. I believe this warning is
meaningless and should be removed. Since I don't think avoiding the
slur matters for AmbitusAccidental would it be fine to set it to any
value? If so then adding (avoid-slur . inside) to the
AmbitusAccidental section of define-grobs.scm would avoid this error.
Is there a better approach? Thanks for the help.

-Jay

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

Re: Clef change placed outside score

[Jay Anderson]

On Wed, Jun 15, 2011 at 6:11 AM, Ralph Palmer ralphbugl...@gmail.com wrote:
 This has  been submitted as Issue 1695 :
 http://code.google.com/p/lilypond/issues/detail?id=1695

Thanks. I think I found a couple workarounds:

musy = \relative c'
{
  \clef treble
  \override Score.NonMusicalPaperColumn #'allow-loose-spacing = ##f
  c4
  \clef bass c4 c c
  \revert Score.NonMusicalPaperColumn #'allow-loose-spacing
}

This isn't the best as the clef now causes space to be made in the other staff.

The other workaround is just changing the tempo to a markup. I prefer
the tempo, but at least with this there isn't the extra space.

Are there other workarounds? Nothing else I tried seemed to work.

-Jay

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

Clef change placed outside score

[Jay Anderson]

\version 2.14.1

%The bass clef in the lower staff is placed to the left of the staff. If either
%the tempo mark is removed or the triplets are changed to a quarter note the
%the clef is placed correctly. This was not an error in 2.12.3.

musx = \relative c'
{
  % Change this to c4 for correct clef placement
  \times 2/3 {c8 c c}

  % Comment this out for correct clef placement
  \tempo asdf

  c4 c c
}

musy = \relative c'
{
  \clef treble c4 \clef bass c4 c c
}

\score
{
  
\new Staff \musx
\new Staff \musy
  
}
attachment: error3.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 1613 in lilypond: Beamed stems too long when avoiding low note in other voice

[Jay Anderson]

On Fri, Apr 15, 2011 at 7:59 AM,  lilyp...@googlecode.com wrote:
 Comment #3 on issue 1613 by bordage@gmail.com: Beamed stems too long
 when avoiding low note in other voice
 http://code.google.com/p/lilypond/issues/detail?id=1613

 Han-Wen's commit has broken Beam_collision_engraver. One example among
 others :

 \relative c'' { d32 ees d c b c b a }

I just installed 2.13.60. The code below results in good beams in
2.13.59, but not in 2.13.60. Does this have the same cause as reported
above? Thanks.

-Jay

\version 2.13.60

\score
{
  \new Staff \relative c''
  {

  { ees4. c8 }
  \\
  { a f8 q q q }

  }
}

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

merge-rests.ily w/ text on full measure rest segfault 2.13.53 (and from git)

[Jay Anderson]

This uses merge-rests.ily which is included with issue 1228
(http://code.google.com/p/lilypond/issues/detail?id=1228). I'm running
ubuntu x86-64 linux (2.6.35-22-generic). Below is a minimal example.
Two things make the segfault go away: remove the mergeRests from the
layout block and removing the markup from the full measure rest. I
hope this is clearer and easier to reproduce than the last
segmentation fault bug I submitted. Thanks for the help!

-Jay

segv2.ly:

\version 2.13.53

\include merge-rests.ily

\layout
{
  \mergeRests
}

music = {R1_asdf |}

\score
{
  \new Staff
  {

  \new Voice
  {
\voiceOne
\music
  }
  \new Voice
  {
\voiceTwo
\music
  }

  }
}


gdb stacktrace:

GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
/home/jay/programming/github/lilypond/out/bin/lilypond...done.
(gdb) run segv2.ly
Starting program:
/home/jay/programming/github/lilypond/out/bin/lilypond segv2.ly
[Thread debugging using libthread_db enabled]
GNU LilyPond 2.13.54
Processing `segv2.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Program received signal SIGSEGV, Segmentation fault.
0x004d3f55 in Grob::extent (this=0x0, refp=value optimized
out, a=X_AXIS) at grob.cc:427
427   if (dim_cache_[a].extent_)
(gdb) where
#0  0x004d3f55 in Grob::extent (this=0x0, refp=value
optimized out, a=X_AXIS) at grob.cc:427
#1  0x004d45b3 in robust_relative_extent (me=0x7fff9350,
refpoint=0x0, a=X_AXIS) at grob.cc:788
#2  0x005c5f3f in centered_on_object (smob=value optimized
out) at self-alignment-interface.cc:69
#3  Self_alignment_interface::x_centered_on_y_parent (smob=value
optimized out) at self-alignment-interface.cc:90
#4  0x005d3c60 in evaluate_with_simple_closure
(delayed_argument=0x72520b70, expr=value optimized out,
pure=false, start=0, end=0) at simple-closure.cc:74
#5  0x005d3bf3 in evaluate_args
(delayed_argument=0x72520b70, expr=0x7fffef72f0c0, pure=false,
start=0, end=0)
at simple-closure.cc:48
#6  evaluate_with_simple_closure (delayed_argument=0x72520b70,
expr=0x7fffef72f0c0, pure=false, start=0, end=0)
at simple-closure.cc:82
#7  0x004c7e46 in Grob::try_callback_on_alist (this=0xbe3000,
alist=0xbe3060, sym=0x72ab51c0, proc=0x7fffef72f0d0)
at grob-property.cc:236
#8  0x004d3ae4 in get_offset (this=0xbe3000, refp=0xc09bd0,
a=value optimized out) at grob.cc:380
#9  Grob::relative_coordinate (this=0xbe3000, refp=0xc09bd0, a=value
optimized out) at grob.cc:309
#10 0x00631a7f in System::get_paper_system (this=0xc09bd0) at
system.cc:510
#11 0x00550b2a in Page_breaking::draw_page
(this=0x7fff9f80, systems=0x7251f810,
configuration=value optimized out, page_num=1, last=true) at
page-breaking.cc:535
#12 0x00551093 in Page_breaking::make_pages
(this=0x7fff9f80, lines_per_page=value optimized out,
systems=0x404)
at page-breaking.cc:603
#13 0x00547183 in Optimal_page_breaking::solve
(this=0x7fff9f80) at optimal-page-breaking.cc:211
#14 0x0054eab5 in ly_optimal_breaking (pb=value optimized
out) at page-breaking-scheme.cc:42
#15 0x00575317 in Paper_book::pages (this=0xc08f20) at paper-book.cc:655
#16 0x00576e21 in Paper_book::output_aux (this=0xc08f20,
output_channel=0x73a0ca20, is_last=true,
first_page_number=0x7fffa270,
first_performance_number=0x7fffa26c) at paper-book.cc:162
#17 0x005779b4 in Paper_book::output (this=0xc08f20,
output_channel=0x73a0ca20) at paper-book.cc:185
#18 0x0044fa2e in ly_book_process (book_smob=value optimized
out, default_paper=0x7211a850,
default_layout=0x71e11d70, output=0x73a0ca20) at book-scheme.cc:79
#19 0x7792caf4 in ?? () from /usr/lib/libguile.so.17
#20 0x005826ef in ly_parse_scm (
s=0xac85dd (let ((book-handler (if (defined?
'default-toplevel-book-handler)\n, ' ' repeats 25 times,
default-toplevel-book-handler\n, ' ' repeats 25 times,
toplevel-book-handler)))\n   (cond ((pair? toplevel-boo...,
n=0x7fffa5a8, i=DWARF-2 expression error: DW_OP_reg operations
must be used either alone or in conjuction with DW_OP_piece or
DW_OP_bit_piece.
)
at parse-scm.cc:139
#21 0x00673a37 in Lily_lexer::yylex (this=0xac6b40) at 

Slur+Dot Collision

[Jay Anderson]

This is not a regression from 2.12. I know how to manually fix it, but
it'd be nice if it avoided the dot automatically.

Related bugs: 868, 1091, 1174, 1230, 1352. I didn't see any listed
related to dot-slur collisions specifically so I thought it may be
useful.

Thanks!

-Jay

\version 2.13.49

\score
{
  \new Staff \relative c'''
  {
\time 6/8
{
  \repeat unfold 6 \repeat unfold 6 g8 |
  g4. e8( f8. c16) | % Collision between dot and slur
}
  }
}

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

Unicode PDF titles garbled

[Jay Anderson]

An example:

\version 2.13.48

\header
{
  title = Non Lo Farò Più
  composer = Johann Baptist Strauß
}

\score
{
  \new Staff c'1
}

When viewing the pdf the title shows as Non Lo Farò Più. I've only
tested this with Evince and Okular. In searching about the problem
people suggest that the text encoding should be utf-16be and include
the BOM (see 
http://stackoverflow.com/questions/3010015/pdfmark-for-docinfo-metadata-in-pdf-is-not-accepting-accented-characters-in-keywo
and http://www.redmine.org/issues/1204).

-Jay

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

Re: Segfault 2.13.47

[Jay Anderson]

On Tue, Feb 1, 2011 at 1:46 PM, Keith OHara k-ohara5...@oco.net wrote:
 ... on both WinXP and Linux and could not find a segfault.

It happens consistently for me (linux 2.6.35, x86_64). Since it's such
a difficult to reproduce, narrow case it's probably best not to worry
about. Filling in the rest of the piece made it go away at least.
Thanks all for looking at it.

-Jay

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

Re: Segfault 2.13.47

[Jay Anderson]

On Sat, Jan 29, 2011 at 11:02 PM, Paul Scott waterho...@ultrasw.com wrote:
 This says 2.13.48.

Right. In order to get debug symbols I built it out of git which is
2.13.48, but I originally saw the error with 2.13.47.

-Jay (fellow arizonian)

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

Re: Segfault 2.13.47

[Jay Anderson]

On Sun, Jan 30, 2011 at 11:27 AM, Keith OHara k-ohara5...@oco.net wrote:
 I wish you luck in making a small example.

 Maybe you can test an earlier Lilypond version on your complete score?

 Do you use Reinhold's new (not yet documented) \partcombineTogether, etc.,
 that appeared in 2.13.35 ?

 To me, the stack trace hints that something went wrong in
 Part_combine_iterator::kill_mmrest(), or data it depends on.  The only
 recent changes to that piece of code were cosmetic, and appeared in 2.13.39
 and 2.13.41.

It actually occurred somewhere between 2.13.45 and 2.13.46 from what I can tell.

More info: I have two parts in the score like this: \partcombine
\bassoonOne \bassoonTwo where not all of \bassoonTwo is filled in
(only a few measures at the beginning are there). But isolating the
score down to just these two parts doesn't result in a segfault. Even
taking out an unrelated part from the score makes the segfault go
away. When I filled in the rest of the part the segfault went away so
this bug may not be likely to happen under normal circumstances (where
both part in partcombine are the same length).

I've attached the whole set of files which cause this since I've been
unable to make a small example. 'score.ly' causes the segfault. Seeing
the segfault was somewhat disconcerting, but it may not especially
severe since it is difficult to isolate and it went away when
completing all the parts.

-Jay


GlazunovReveries.tar.bz2
Description: BZip2 compressed data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Segfault 2.13.47

[Jay Anderson]

Below is the gdb trace from the segfault:

GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
/home/jay/programming/github/lilypond/out/bin/lilypond...done.
(gdb) run score
Starting program: /home/jay/programming/github/lilypond/out/bin/lilypond score
[Thread debugging using libthread_db enabled]
GNU LilyPond 2.13.48
Processing `score.ly'
Parsing...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music...
Interpreting music... [8][16]
flute2.ily:15:28: warning: No tuplet to end
  \times 2/3 {r8 r ees(\mf}
\times 2/3 {c ees c} \times 2/3 {d ces d)} |
flute2.ily:15:49: warning: No tuplet to end
  \times 2/3 {r8 r ees(\mf} \times 2/3 {c ees c}
 \times 2/3 {d ces d)} |
flute2.ily:16:2: warning: No tuplet to end

  \times 2/3 {bes( ees bes} \times 2/3 {ees bes ees} \times 2/3 {bes ees) r} |
flute2.ily:16:28: warning: No tuplet to end
  \times 2/3 {bes( ees bes}
\times 2/3 {ees bes ees} \times 2/3 {bes ees) r} |
flute2.ily:16:53: warning: No tuplet to end
  \times 2/3 {bes( ees bes} \times 2/3 {ees bes ees}
 \times 2/3 {bes ees) r} |
flute2.ily:17:27: warning: No tuplet to end
  \times 2/3 {r8 r des(\}
   \times 2/3 {bes des bes} \times 2/3 {c a c)} s1*0\! |
flute2.ily:17:52: warning: No tuplet to end
  \times 2/3 {r8 r des(\} \times 2/3 {bes des bes}
\times 2/3 {c a c)} s1*0\! |
flute2.ily:18:2: warning: No tuplet to end

  \times 2/3 {f,8( bes f} \times 2/3 {bes f bes} \times 2/3 {f bes) r} |
flute2.ily:18:26: warning: No tuplet to end
  \times 2/3 {f,8( bes f}
  \times 2/3 {bes f bes} \times 2/3 {f bes) r} |
flute2.ily:18:49: warning: No tuplet to end
  \times 2/3 {f,8( bes f} \times 2/3 {bes f bes}
 \times 2/3 {f bes) r} |
flute2.ily:19:5: warning: No tuplet to end
  r4
 \times 2/3 {e,8(\pp\justCrescPoco g) e'(\!} \times 2/3 {g e) r} |
flute2.ily:19:49: warning: No tuplet to end
  r4 \times 2/3 {e,8(\pp\justCrescPoco g) e'(\!}
 \times 2/3 {g e) r} |
[24]
flute2.ily:20:5: warning: No tuplet to end
  r4
 \times 2/3 {ees,8( g) ees'(} \times 2/3 {g ees) r} |
flute2.ily:20:34: warning: No tuplet to end
  r4 \times 2/3 {ees,8( g) ees'(}
  \times 2/3 {g ees) r} |
[32][40][48][56][64]
Preprocessing graphical objects...
Interpreting music...
Program received signal SIGSEGV, Segmentation fault.
Prob::internal_get_property (this=0x0, sym=0x73a6e880) at prob.cc:163
163   SCM s = scm_sloppy_assq (sym, mutable_property_alist_);
(gdb) where
#0  Prob::internal_get_property (this=0x0, sym=0x73a6e880) at prob.cc:163
#1  0x0047fc34 in Dispatcher::dispatch (this=value optimized
out, sev=value optimized out) at dispatcher.cc:79
#2  0x005792c5 in substitute_both (this=0x157a170, m=value
optimized out) at part-combine-iterator.cc:205
#3  chords_together (this=0x157a170, m=value optimized out) at
part-combine-iterator.cc:325
#4  Part_combine_iterator::process (this=0x157a170, m=value optimized
out) at part-combine-iterator.cc:458
#5  0x005c1de7 in Sequential_iterator::process
(this=0x1720290, until=DWARF-2 expression error: DW_OP_reg operations
must be used either alone or in conjuction with DW_OP_piece or
DW_OP_bit_piece.
) at sequential-iterator.cc:221
#6  0x005230ac in Music_wrapper_iterator::process (this=value
optimized out, m=value optimized out)
at music-wrapper-iterator.cc:70
#7  0x005ce921 in Simultaneous_music_iterator::process
(this=value optimized out, until=DWARF-2 expression error: DW_OP_reg
operations must be used either alone or in conjuction with DW_OP_piece
or DW_OP_bit_piece.
)
at simultaneous-music-iterator.cc:94
#8  0x005230ac in Music_wrapper_iterator::process (this=value
optimized out, m=value optimized out)
at music-wrapper-iterator.cc:70
#9  0x005ce921 in Simultaneous_music_iterator::process
(this=value optimized out, until=DWARF-2 expression error: DW_OP_reg
operations must be used either alone or in conjuction with DW_OP_piece
or DW_OP_bit_piece.
)
at simultaneous-music-iterator.cc:94
#10 0x004b1f94 in 

Re: New language feature breaks lilypond-words

[Jay Anderson]

On Sun, Dec 19, 2010 at 12:27 AM, Patrick McCarty pnor...@gmail.com wrote:
 Not sure how to implement a proper fix at the moment, so I've opened a
 tracker issue:

 https://code.google.com/p/lilypond/issues/detail?id=1457

Thanks for looking into this. In my local lilypond install I've
disabled syntax highlighting for embedded scheme in the meantime.

-Jay

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

Re: New language feature breaks lilypond-words

[Jay Anderson]

On Sat, Dec 11, 2010 at 5:09 PM, Patrick McCarty pnor...@gmail.com wrote:
 Thanks for the report, Jay.  The note-name definitions have just moved
 from the ly/ directory to the scm/ directory, so I've adapted your
 patch to use the new location.

Thanks for taking care of this. Much faster than I expected.

Here's another lilypond vim annoyance. Take these lines as examples:

\version 2.13.42
\once \override Staff.DynamicText #'self-alignment-X = #LEFT

If you place the cursor over the 2 in the first line or over the S
in Staff in the second line and type 'dw' (delete word) it will treat
the dots as word characters and result in these lines:

\version 
\once \override #'self-alignment-X = #LEFT

I would expect it to stop at the dots. I haven't looked too much at
the syntax file yet to see how this might be easily fixed.

Thanks for the help!

-Jay

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

New language feature breaks lilypond-words

[Jay Anderson]

This is a small annoyance, but one I didn't see reported.
lilypond-words.py used the language files to generate the list of
lilypond words. Since these language files now only include \language
mylanguage many note names are not being found. The result is vim
syntax highlighting (and I imagine also emacs) doesn't highlight many
note names. A suggested patch is at the end of this email. I adjusted
the regular expression so it wouldn't include the language name as
part of note_names. Thanks.

-Jay

diff --git a/scripts/build/lilypond-words.py b/scripts/build/lilypond-words.py
index ef6328f..d65ecdb 100644
--- a/scripts/build/lilypond-words.py
+++ b/scripts/build/lilypond-words.py
@@ -47,21 +47,8 @@ for name in ['ly/chord-modifiers-init.ly',
 keywords += [w for w in re.findall (r(?m)^\s*\?([a-zA-Z]+)\?\s*=, s)]

 # note names
-for name in ['ly/catalan.ly',
- 'ly/deutsch.ly',
- 'ly/drumpitch-init.ly',
- 'ly/english.ly',
- 'ly/espanol.ly',
- 'ly/italiano.ly',
- 'ly/makam.ly',
- 'ly/nederlands.ly',
- 'ly/norsk.ly',
- 'ly/portugues.ly',
- 'ly/suomi.ly',
- 'ly/svenska.ly',
- 'ly/vlaams.ly']:
-s = open (name, 'r').read ()
-note_names += [n for n in re.findall
(r(?m)^\s*\(([a-z]+)[^l]+ly:make-pitch, s)]
+s = open ('ly/language-init.ly', 'r').read ()
+note_names += [n for n in re.findall
(r(?m)^\s*\(([a-z]+)\s*\.\s*,\(ly:make-pitch, s)]

 # reserved words
 for name in ['ly/engraver-init.ly',

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

Re: DynamicTextSpanner is not fully contained in parent spanner

[Jay Anderson]

On Sun, Sep 12, 2010 at 12:55 PM, Neil Puttock n.putt...@gmail.com wrote:
 You can still use the old method for hiding lines:

 \override DynamicTextSpanner #'dash-period = #-1

Yeah, it looks like this is the preferred method since it doesn't have
this line break problem.

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

Re: Tempo Segmentation Fault

[Jay Anderson]

On Fri, Sep 10, 2010 at 1:07 AM, Phil Holmes m...@philholmes.net wrote:
 Related to this?

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

Yep, that's it. I guess I missed it in my searching. Thanks.

-Jay

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

Re: DynamicTextSpanner is not fully contained in parent spanner

[Jay Anderson]

On Fri, Sep 10, 2010 at 12:52 AM, Urs Liska lilyli...@googlemail.com wrote:
 Am 10.09.2010 06:33, schrieb Jay Anderson:

 \version 2.13.32

 \score
 {
   \new Staff \relative c'
   {
     %Works fine over break:
     c1\cresc
     \break
     c1\f

     \override DynamicTextSpanner #'style = #'none
     c1\cresc
     \break
     c1\f
   }
 }

 dts.ly:13:6: programming error: Spanner `DynamicTextSpanner' is not
 fully contained in parent spanner. Ignoring orphaned part
     c1
       \cresc


 I can't tell if there is some valid reason that this shouldn't be allowed.
 So I added is as http://code.google.com/p/lilypond/issues/detail?id=1259

This is definitely a hack, but it works for me:

diff --git a/lily/spanner.cc b/lily/spanner.cc
index 32e0d21..827f5d6 100644
--- a/lily/spanner.cc
+++ b/lily/spanner.cc
@@ -112,6 +112,8 @@ Spanner::do_break_processing ()

  bool ok = parent_rank_slice.contains
(bounds[LEFT]-get_column ()-get_rank ());
  ok = ok  parent_rank_slice.contains
(bounds[RIGHT]-get_column ()-get_rank ());
+
+  ok = ok || ly_symbol2scm(none) == get_property (style);

  if (!ok)
{

I haven't spent the time to understand how things work yet, but this
at least gets me past this problem for now.

-Jay

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

Tremolo + Chord Repetition Error

[Jay Anderson]

\version 2.13.32

\new Staff \relative c'
{
  %Causes error:
  c e8 q q q \repeat tremolo 4 q |

  %This works:
  %c e8 q q q \repeat tremolo 4 c e |
}

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

This has an easy workaround, but it took me a while to track down
because of the unhelpful error.

-Jay

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

DynamicTextSpanner is not fully contained in parent spanner

[Jay Anderson]

\version 2.13.32

\score
{
  \new Staff \relative c'
  {
%Works fine over break:
c1\cresc
\break
c1\f

\override DynamicTextSpanner #'style = #'none
c1\cresc
\break
c1\f
  }
}

dts.ly:13:6: programming error: Spanner `DynamicTextSpanner' is not
fully contained in parent spanner. Ignoring orphaned part
c1
  \cresc

As a result the 'cresc' is not printed. The closest issue I could find
is 1089 (http://code.google.com/p/lilypond/issues/detail?id=1089).

-Jay

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

Tempo Segmentation Fault

[Jay Anderson]

\version 2.13.32

\score
{
  
\new Staff
{
  \tempo Andante 4=63
  R1
}
\new Staff
{
  R1
}
  
  \layout
  {
  }
}

$ lilypond seg.ly
GNU LilyPond 2.13.32
Processing `seg.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...Segmentation fault

How to make the segmentation fault go away:
- Remove the tempo indication
- Change the multi-measure rest to a note
- Remove the second staff

Thanks for the help!

-Jay

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

Re: Text cresc *without dashed line* and Y-offset

[Jay Anderson]

On Sun, May 30, 2010 at 2:03 PM, Neil Puttock n.putt...@gmail.com wrote:
 On 28 May 2010 17:48, Xavier Scheuer x.sche...@gmail.com wrote:

 Shouldn't we open an issue about this on the tracker, at least to
 keep track on this discussion and your very interesting proposal?

 I should have a patch sorted later, so there's no need to log this on
 the tracker.  Once I've refreshed the (approved) patch for issue #305,
 I'll add the enhancement for DynamicTextSpanners.

As a side note, I've started using the following for cresc. markings
without a dashed line:

justcresc = #(make-music 'CrescendoEvent 'span-direction START
'span-type 'text 'span-text cresc. 'tweaks '((dash-period . -1.0)))

-Jay

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

cueDuring + tuplet warning

[Jay Anderson]

\version 2.13.22

one = \relative c'
{
  c4 c c \times 2/3 {c8 c c} |
  c8 c c c c c c c |
}

\addQuote ONE \one

two = \relative c'
{
  R1 |
  \cueDuring #ONE #UP {R1 |}
}

\score { \new Staff \two }
==

Results in this warning:
cue_prob.ly:5:9: warning: No tuplet to end
  c4 c c
 \times 2/3 {c8 c c} |

This doesn't seem detrimental to the output, but it is seems to be an
unneeded warning since the tuplet isn't part of the desired cue.

-Jay

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

Re: RhythmicStaff Multimeasure Rests

[Jay Anderson]

On Tue, Mar 9, 2010 at 3:19 PM, Neil Puttock n.putt...@gmail.com wrote:
 \override RhythmicStaff.MultiMeasureRest #'staff-position = #0.01

Thanks. That works great.

Now I just have to deal with
\context{\RemoveEmptyRhythmicStaffContext} killing my settings. I
remember following the discussion recently, but I couldn't find a bug.
Was one written?

It's especially annoying here.

If I put this in a common file included by both the score and the part:
\layout
{
  \context
  {
\RemoveEmptyRhythmicStaffContext
  }
  \context
  {
\RhythmicStaff
\override MultiMeasureRest #'staff-position = #0.01
  }
}

Then the score looks fine, but since the bass drum (or triangle or
other percussion instrument) rest for very long sections some of the
lines in the part are taken out.

The alternative is to move the RemoveEmptyRhythmicStaffContext to the
score file and duplicate the multimeasure rest stuff below it again.
This is what I'm doing. (Though I should probably put in some cues
which would also fix this).

The cleanest solution would be for either the
RemoveEmptyRhythmicStaffContext to not kill settings or if there is
only one staff in the score the RemoveEmptyRhythmicStaffContext would
just not remove anything (or both of course).

Really these are minor inconveniences. I just want to be sure bugs. Thanks.

-Jay


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

Re: RhythmicStaff Multimeasure Rests

[Jay Anderson]

On Fri, Mar 5, 2010 at 10:31 PM, Jay Anderson horndud...@gmail.com wrote:
 \version 2.13.15
 \new RhythmicStaff
 {
  %\override Staff.MultiMeasureRest #'extra-offset = #'(0 . -1)
  R1
 }

Of course this doesn't quite work because all multi measure rests are
moved and not just single whole measure rests.

I've been messing with this:

\override Staff.MultiMeasureRest #'extra-offset =
#(lambda (grob)
  '(0 . -1))

I only want to return '(0 . -1) if the multi measure rest length is
the same as the length of a full bar. To get at the measure length I
need to do something like (ly:context-property context 'measureLength
#f). How can I get at the context from a callback function like the
one above? or is there a better way to move all full measure rests
down?

It's interesting to me that in this example the whole rest in the last
measure works correctly:
\new RhythmicStaff
{
  \time 6/4
  R1.
  R1.*10
  r1 r2
}

Thanks.

-Jay


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

Tuplet bracket over tremolo

[Jay Anderson]

\version 2.13.15
\new Staff
{
  %\override TupletBracket #'transparent = ##t
  \times 2/3 {\repeat tremolo 3 c'8}
}

In previous versions the above worked as expected: a '3' over a dotted
quarter with a eighth tremolo beam. (I've use this in 2.12 without
problems.) With the latest 2.13.15 release the brackets are now
visible and colliding with the number. Was this an intentional change
in behavior or a regression?

Easy workaround: make the bracket transparent.

Thanks.

-Jay


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

RhythmicStaff Multimeasure Rests

[Jay Anderson]

\version 2.13.15
\new RhythmicStaff
{
  %\override Staff.MultiMeasureRest #'extra-offset = #'(0 . -1)
  R1
}

The rest should be below the staff line instead of floating above the
staff line. It looks like it's placed where it would be on a 5 line
staff (below 2nd line from the top). Uncomment the override and it
will look as expected. Should this (or a better fix) be added to
engraver-init.ly? Thanks.

-Jay
attachment: rhy_test.preview.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Issue 641 in lilypond: error: script direction not yet known when using implicit Voice contexts

[Jay Anderson]

On Thu, Feb 18, 2010 at 9:50 PM,  lilyp...@googlecode.com wrote:
 % This example has the same fix/workaround as issue 641.
 % There is no warning in this case. Instead the hairpins
 % end at the end of the markup instead of at the correct
 % location.

I spoke too soon. I can't figure out how to work around the issue in
piano centered dynamics:

\version 2.13.13

left = {\repeat unfold 16 c''16}
dyn = {s4\ s2.\!^\markup{Hello Hello Hello!}}
right = {\clef bass \repeat unfold 16 c16}

\score
{
  \new PianoStaff
  
\new Staff \left
\new Dynamics \dyn
\new Staff \right
  
}

Adding either the key or the new voice don't seem to do the trick.
Thanks for the help.

-Jay


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

Re: auto-beam in pickup-bars with grace note

[Jay Anderson]

grisu_76 christian.hummer at univie.ac.at writes:
 Some ideas? regards, Christian

See issue 372:
http://code.google.com/p/lilypond/issues/detail?id=372

-Jay



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

Re: Programming error: script direction not yet known

[Jay Anderson]

\new Voice is a better option to avoid adding a key signature when
transposing. Enhancement is fine. Thanks!

-Jay

On Wed, Jun 18, 2008 at 12:39 AM, Valentin Villenave
[EMAIL PROTECTED] wrote:
 2008/6/18 Jay Anderson [EMAIL PROTECTED]:

 Adding a key signature fixes the errors.

 ... Or explicitly using \new Voice.

 I don't know if this can really be regarded as a bug or not.

 I've marked it as an Enhancement, since the workaround is easy.
 http://code.google.com/p/lilypond/issues/detail?id=641

 Cheers,
 Valentin



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

Programming error: script direction not yet known

[Jay Anderson]

\version 2.11.49

\new Staff \relative c''
{
  %\key c \major %Add a key to correct programming errors.
  
{ c16 e a g f e d c }
{ s16( s) s-. s-. s( s) s-. s-. }
  
}

I didn't find this one in the bug tracker. I'm swapping out the rhythm
on the same passage and this error is created for each staccato:

test.ly:8:15: warning: programming error: script direction not yet known
{ s16( s) s
   -. s-. s( s) s-. s-. }

No slurs are created it seems and the dots are placed strangely.
Adding a key signature fixes the errors.

-Jay


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

Text from decrescendo spanner not kept inside line

[Jay Anderson]

Below the sempre dim. isn't kept inside the line. Shouldn't this be
taken into account? The workaround of course is to put a manual
\noBreak in.

-Jay

\version 2.11.49

\score
{
  \new Staff \relative c'
  {
\override Score.PaperColumn #'keep-inside-line = ##t
\override Score.NonMusicalPaperColumn #'keep-inside-line = ##t
\repeat unfold 10 c1 |
\set decrescendoText = \markup {\italic sempre dim.}
\set decrescendoSpanner = #'text
\override DynamicTextSpanner #'style = #'dashed-line
c4 c c c\ | \break
\repeat unfold 10 c1 |
c1\! |
  }
}


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

Re: Minor vim syntax improvements

[Jay Anderson]

If you look at dynamic-scripts-init.ly the forte dynamic is defined like this:

f = #(make-dynamic-script f)

So when the keywords file is generated this very common dynamic was missing.

-Jay

On Tue, May 20, 2008 at 12:44 AM, Graham Percival [EMAIL PROTECTED] wrote:
 Thanks for the patch.

 I applied the changes to vim/lilypond-syntax.vim.  However, I
 don't understand the change to buildscripts/lilypond-words.py, so I
 did not apply it.


 For anybody else interested: the change in question is replacing line
 39 of buildscripts/lilypond-words.py:
 -keywords += [w for w in re.findall (r(?m)^\s*([a-zA-Z]+)\s*=, s)]
 +keywords += [w for w in re.findall (r(?m)^\s*\?([a-zA-Z]+)\?
 \s*=, s)]

 Cheers,
 - Graham


 On Sat, 17 May 2008 16:36:53 -0700
 Jay Anderson [EMAIL PROTECTED] wrote:

 Attached is a patch which should make forte dynamic highlighted. It
 also fixes this: 'c--\mf'. Normally the second '-' is highlighted with
 the \mf which isn't right. Let me know if things seem ok (I've never
 submitted a patch before).

 -Jay




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

Minor vim syntax improvements

[Jay Anderson]

Attached is a patch which should make forte dynamic highlighted. It
also fixes this: 'c--\mf'. Normally the second '-' is highlighted with
the \mf which isn't right. Let me know if things seem ok (I've never
submitted a patch before).

-Jay
From 54cd24f12d19385b244ef027268ccd49e89f360b Mon Sep 17 00:00:00 2001
From: Jay Anderson [EMAIL PROTECTED]
Date: Sat, 17 May 2008 16:16:37 -0700
Subject: [PATCH] Minor fixes for vim syntax highlighting.

---
 buildscripts/lilypond-words.py |2 +-
 vim/lilypond-syntax.vim|6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/buildscripts/lilypond-words.py b/buildscripts/lilypond-words.py
index 123041b..eacece2 100755
--- a/buildscripts/lilypond-words.py
+++ b/buildscripts/lilypond-words.py
@@ -39,7 +39,7 @@ for name in ['ly/chord-modifiers-init.ly',
  'ly/declarations-init.ly',
  'ly/params-init.ly']:
 s = open (name, 'r').read ()
-keywords += [w for w in re.findall (r(?m)^\s*([a-zA-Z]+)\s*=, s)]
+keywords += [w for w in re.findall (r(?m)^\s*\?([a-zA-Z]+)\?\s*=, s)]
 
 # note names
 for name in ['ly/catalan.ly',
diff --git a/vim/lilypond-syntax.vim b/vim/lilypond-syntax.vim
index 9808176..7d0a6d8 100644
--- a/vim/lilypond-syntax.vim
+++ b/vim/lilypond-syntax.vim
@@ -33,7 +33,7 @@ setlocal mps+=:
  Case matters
 syn case match
 
-syn cluster lilyMatchGroup	contains=lilyMatcher,lilyString,lilyComment,lilyStatement,lilyNumber,lilyEquation,lilySlur,lilySpecial,lilyNote,lilyKeyword,lilyReservedWord
+syn cluster lilyMatchGroup	contains=lilyMatcher,lilyString,lilyComment,lilyStatement,lilyNumber,lilyEquation,lilySlur,lilySpecial,lilyNote,lilyKeyword,lilyArticulation,lilyReservedWord
 
 syn region lilyMatcher	matchgroup=Delimiter start={ skip=\|\\[]	end=}	[EMAIL PROTECTED] fold
 syn region lilyMatcher	matchgroup=Delimiter start=\[		end=]	[EMAIL PROTECTED] fold
@@ -48,6 +48,9 @@ syn match lilyEquation	\(#['`]\)\?\(\a*[-]\)*\a*\s*=\s*\(#[#'`]\?\)\?\a*
 syn match lilySlur	[(~)]
 syn match lilySlur	\\[()]
 syn match lilySpecial	\\[!\\]
+ avoid highlighting the extra character in situations like
+ c--\mf c^^\mf c__\mf
+syn match lilyArticulation	[-_^][-_^+|.]
 
  Rest of syntax highlighting rules start here
 
@@ -68,6 +71,7 @@ if version = 508 || !exists(did_lily_syn_inits)
   HiLink lilyComment	Comment
  
   HiLink lilyNote	Identifier
+  HiLink lilyArticulation	PreProc
   HiLink lilyKeyword	Keyword
   HiLink lilyReservedWord	Type
 
-- 
1.5.4.3

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

Another arpeggio collision

[Jay Anderson]

When using cross staff arpeggios a collision can occur if accidentals
cause the arpeggio to be moved to the left too much.

(Possible related issue: 556)

Thanks!

-Jay

\version 2.11.42

\paper
{
  ragged-right = ##t
}

\book
{
  \new PianoStaff
  
\set PianoStaff.connectArpeggios = ##t
\new Staff=RH \relative c''
{
  r2. ges aes c ges'4\arpeggio |
}

\new Staff=LH \relative c'
{
  \repeat unfold 12 aes16 ees aes c4\arpeggio |
}
  
}

It is interesting to note that this does not occur with one staff and
two voices:

  \new Staff
  \with
  {
\consists Span_arpeggio_engraver
  }
  \relative c''
  {
\set Staff.connectArpeggios = ##t

  {r2. ges aes c ges'4\arpeggio |}
  \\
  {\repeat unfold 12 aes,16 ees aes c4\arpeggio |}

  }


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

vim no formatting for \f

[Jay Anderson]

I would expect \f to look similar to other dynamic markings like \p or
\mf when using vim. Adding it to the
.../usr/share/lilypond/current/vim/syntax/lilypond-words.vim will fix
this. Thanks!

-Jay


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

Re: Another arpeggio collision

[Jay Anderson]

Great! Thanks that worked wonderfully. Thanks!

On Fri, Mar 28, 2008 at 2:41 PM, Neil Puttock [EMAIL PROTECTED] wrote:
 Hi Jay,

  I've noticed this happening recently. As a workaround I've been
  setting #'infinite-spacing-height = ##t whenever it occurs.

  Here's a related example with one stave and two voices where the
  arpeggio collides with the time signature:


  \version 2.11.42
  \paper { ragged-right = ##t }

 \new Staff
   \with
   {
\consists Span_arpeggio_engraver
   }
   \relative c''
   {
\set Staff.connectArpeggios = ##t

  {ces\arpeggio}
  \\
  {es,\arpeggio }

   }

  Regards,
  Neil



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

Re: repeatTie does not work in chords

[Jay Anderson]

Papa Eric papa.eric at free.fr writes:
 
 This adds a repeat tie on both notes,
 not only b:
 

Try:  \new Voice {b\repeatTie} g' 

It's ugly and you'll get a warning, but I think it will do what you want.

-Jay



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

Unwanted tie direction

[Jay Anderson]

This seems very similar to issues 440 and 434, but here there is no
forced line break. I can't really tell if it is the same exact issue
or not.

-Jay

\version 2.11.42

\paper
{
  ragged-right = ##t
}

\score
{
  \new Staff \relative c''
  {
b1~ | b~ | b2 r |
  }
}


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

Re: keep-inside-line doesn't adjust for long marks

[Jay Anderson]

Great that worked. Unfortunately I had to have both:

\override Score.PaperColumn #'keep-inside-line = ##t
\override Score.NonMusicalPaperColumn #'keep-inside-line = ##t

Your suggestion worked on the mark but not on the markup. So I use
both and I'm good. Thanks!

-Jay

On 10/2/07, Joe Neeman [EMAIL PROTECTED] wrote:
 On 10/3/07, Jay Anderson [EMAIL PROTECTED] wrote:
  This would be nice to have, but it's not a huge problem. At the very least
  perhaps a comment should be added to section 5.7 Avoiding tweaks with
  slower
  processing which states that keep-inside-line doesn't affect marks.

 I'm not at home or I'd try this for myself, but what if you use
 \override Score.NonMusicalPaperColumn #'etc...
 instead of PaperColumn?

 Joe



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

keep-inside-line doesn't adjust for long marks

[Jay Anderson]

This would be nice to have, but it's not a huge problem. At the very least
perhaps a comment should be added to section 5.7 Avoiding tweaks with slower
processing which states that keep-inside-line doesn't affect marks.

Thanks for the great work!

-Jay Anderson

\version 2.11.34

\score
{
  \new Staff \relative c'
  {
\time 4/4
\override Score.PaperColumn #'keep-inside-line = ##t
\repeat unfold 9 { c1 }

%This one is fixed
c1_\markup{A Long Markup Which Goes Off The Page}
\repeat unfold 8 { c1 }

%This mark still goes off the page.
\mark A Long Mark Goes Way Off The Page
\repeat unfold 12 { c1 }
  }
}




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

Re: \appoggiatura disables autoBeam

[Jay Anderson]

Mats Bengtsson mats.bengtsson at ee.kth.se writes:
 I'm really surprised that this issue hasn't popped
 up earlier.

I remember running into this a couple of months back
(http://article.gmane.org/gmane.comp.gnu.lilypond.bugs/10045). I believe the
plan was to add it to issue 34
(http://code.google.com/p/lilypond/issues/detail?id=34). I found a workaround
that I was happy with and kinda forgot to add comments to the issue. I can do
that now unless we want to create a new issue. Let me know. In any case I think
a better workaround is to add some space before the grace note. This will keep
the key signature where you want it.

\version 2.11.22
\score {
 \new PianoStaff 
   \relative c''

   \new Staff {
\key g \minor
\partial 4.
s8

\appoggiatura g'16
f8 ees16 d
c8-3 (bes) bes4. d8-2 g d
   }

   \relative c'
   \new Staff {
\key g \minor
\partial 4.
s8
r4
r8 bes8 (d f d bes d g)
   }
 
}

-Jay



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

Staff.voltaOnThisStaff = ##t is default

[Jay Anderson]

I'm not totally sure this is a bug or a decision, but it conflicts with what is
stated in the manual in section 6.7.2 Repeat syntax: Brackets for the repeat
are normally only printed over the topmost staff. I think I prefer it set to
false. Also see:
http://lilypond.org/doc/v2.11/Documentation/user/source/input/lsr/repeats/collated-files#volta-multi-staff.ly

Thanks!

-Jay



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

Re: cross staff/voice arpeggio error

[Jay Anderson]

I'm not certain that this is a real bug (I think it's invalid input; see
the warning)


I can see that, but how do you accomplish an arpeggio between voices
otherwise? I want to be able to have an arpeggio extend across voices
in different staves and across different voices in the same staff.
This was how I was able to do it in previous versions of lilypond.

If I do '\new Staff \with {\consists Span_arpeggio_engraver}' along
with '\set Staff.connectArpeggios = ##t' inside that staff,
cross-voice arpeggios work in that one staff. If I do '\set
PianoStaff.connectArpeggios = ##t' instead I get the error of course.
Is there another option which would allow for both? Thanks again for
looking at this.

-Jay Anderson

\version 2.11.21
\layout { ragged-right = ##t }

\new PianoStaff 
\set PianoStaff.connectArpeggios = ##t
\new Staff \with {\consists Span_arpeggio_engraver}
\relative c'' {
  \set Staff.connectArpeggios = ##t
  
{
  c1\arpeggio
}
\\
{
  g2\arpeggio a
}
  
}





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

cross staff/voice arpeggio error

[Jay Anderson]

The example below produces garbled output. If you add \arpeggio to the
first c2 in the top staff no errors are produced (except I don't want
the arpeggio to extend up there :). Here's the error:

GNU LilyPond 2.11.21
Processing `test3.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
warning: vertical alignment called before line-breaking.
Only do cross-staff spanners with PianoStaff.
Layout output to `test3.ps'...
Converting to `test3.pdf'...

\version 2.11.21

\layout
{
 ragged-right = ##t
}

\new PianoStaff

 \set PianoStaff.connectArpeggios = ##t

 \new Staff
 \relative c''
 {
   c2 c2\arpeggio
 }
 \new Staff
 \relative c''
 {
   
 {
   c2\arpeggio c2\arpeggio
 }
 \\
 {
   g4\arpeggio a g4\arpeggio a
 }
   
 }




-Jay Anderson


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

Re: segfault 2.11.20

[Jay Anderson]

I haven't been able to get a good reduced example. A full piece which has a
segfault on my linux box and the malloc error on my wife's mac can be looked at
with subversion: 'svn co
https://open-scores.svn.sourceforge.net/svnroot/open-scores/DukasVillanelle/trunk
DukasVillanelle' Try to compile Piano.ly. Is there something odd that I'm doing.
One thing that probably does need to be looked at is the Piano centered
dynamics.  There was talk a month or so ago about re-doing this. Any tips on
where to start for working on that? In any case thanks for the help. Let me know
if there's anything else that you'd like me to try.

-Jay



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

Re: segfault 2.11.20

[Jay Anderson]

I just installed lilypond on my wife's mac and just as your say this
example does not produce a segfault. I went back to try the real
lilypond file and on the mac I'm getting this error repeated over and
over:

lilypond(300) malloc: ***  Deallocation of a pointer not malloced:
0xbfffb480; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug

I'm thinking this is the same reason I was getting the segfault on my
linux box. I'll research this a bit more and get you a better example
that produces the problem in both environments.

-Jay

On 2/27/07, Graham Percival [EMAIL PROTECTED] wrote:

I have no problems compiling this (with everything un-commented out) on
OSX.  Could you check to make sure the example fails to compile, and
that you copied the right file?

Cheers,
- Graham


Jay Anderson wrote:
 I can't narrow this one down too much, it's really weird. For example
 when I remove the two commented out lines the segfault goes away.

 -Jay

 (I'm on Fedora Core 6)

 =
 \version 2.11.20

 \score
 {
  \new PianoStaff
  
\new Staff=RH \relative c'
{
  c4 d e f |
}

\new Dynamics = dynamics
{
  \time 4/4 s1 |
}

\new Staff=LH
\relative c
{
  \clef bass
c4 d e f |
}
  
  \layout
  {
\context
{
  \type Engraver_group
  \name Dynamics
  \alias Voice
  \consists Output_property_engraver

  \override VerticalAxisGroup #'minimum-Y-extent = #'(-1 . 1)
  pedalSustainStrings = #'(Ped. *Ped. *)
  pedalUnaCordaStrings = #'(una corda  tre corde)

  \consists Piano_pedal_engraver
  \consists Script_engraver
  \consists Dynamic_engraver
  \consists Text_engraver

  %\override TextScript #'font-size = #2
  %\override TextScript #'font-shape = #'italic
  \override TextScript #'extra-offset = #'(0 . 1.75)
  \override DynamicText #'extra-offset = #'(0 . 2.5)
  \override Hairpin #'extra-offset = #'(0 . 2.5)

  \consists Skip_event_swallow_translator

  \consists Axis_group_engraver
}
\context
{
  \PianoStaff
  \accepts Dynamics
}
  }
 }
 =


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






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

segfault 2.11.20

[Jay Anderson]

I can't narrow this one down too much, it's really weird. For example
when I remove the two commented out lines the segfault goes away.

-Jay

(I'm on Fedora Core 6)

=
\version 2.11.20

\score
{
 \new PianoStaff
 
   \new Staff=RH \relative c'
   {
 c4 d e f |
   }

   \new Dynamics = dynamics
   {
 \time 4/4 s1 |
   }

   \new Staff=LH
   \relative c
   {
 \clef bass
   c4 d e f |
   }
 
 \layout
 {
   \context
   {
 \type Engraver_group
 \name Dynamics
 \alias Voice
 \consists Output_property_engraver

 \override VerticalAxisGroup #'minimum-Y-extent = #'(-1 . 1)
 pedalSustainStrings = #'(Ped. *Ped. *)
 pedalUnaCordaStrings = #'(una corda  tre corde)

 \consists Piano_pedal_engraver
 \consists Script_engraver
 \consists Dynamic_engraver
 \consists Text_engraver

 %\override TextScript #'font-size = #2
 %\override TextScript #'font-shape = #'italic
 \override TextScript #'extra-offset = #'(0 . 1.75)
 \override DynamicText #'extra-offset = #'(0 . 2.5)
 \override Hairpin #'extra-offset = #'(0 . 2.5)

 \consists Skip_event_swallow_translator

 \consists Axis_group_engraver
   }
   \context
   {
 \PianoStaff
 \accepts Dynamics
   }
 }
}
=


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

bug 279

[Jay Anderson]

When compiling the example provided with bug 279
(http://code.google.com/p/lilypond/issues/detail?id=279) I get the
following error:

GNU LilyPond 2.11.19
Processing `test.ly'
Parsing...
Interpreting music...
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][117]
Preprocessing graphical objects...ERROR: In procedure
ly:tuplet-bracket::calc-positions:
ERROR: Wrong type (expecting real number): ()

When I take out the spacing (or turn it down to 57 measures) the beam
of the first group of triplets is floating above both staffs. Is the
example flawed? Is there a better way to accomplish this. Thanks for
the help!

-Jay

(I'm using FC6 incase that's important.)


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

Re: Text Spanners broken in 2.11.17

[Jay Anderson]

 \override Glissando #'bound-details #'right #'text = \markup {
\hcenter \bold down }

... which works for text spanners, too.

Two overrides now instead of one (if you're wanting to override edge
text at both the left and right of the spanner). But the upside is
that padding and positioning of left and right edges of spanners can
now be set completely independently.


Perfect! Looking at the manual again I see this is in the previous
section where it describes the properties. Oops. Also for most use
cases it's still only one override. The left text is used more often
than the right (for me at least). Thanks for the help!

-Jay


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

grace + partial autobeaming problem

[Jay Anderson]

It seems when a piece starts with a grace in a partial measure the
autobeaming for the rest of the piece gets messed up. A work around is
to add a spacer rest to the start.

\version 2.11.18

\paper { ragged-right = ##t }

\score
{
 \new Staff
 \relative c'
 {
   \partial 8
   \grace c16 c c c c c c c8 c c c c c
 }
}

\score
{
 \new Staff
 \relative c'
 {
   \partial 4
   s8 \grace c16 c c c c c c c8 c c c c c
 }
}


test.preview.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Text Spanners broken in 2.11.17

[Jay Anderson]

The examples in section 8.1.3 Text spanners in the 2.11.17 manual are broken.
The text is missing from the spanners. Is there a new way to do this or is this
a regression? I haven't seen this mentioned yet on this list or in the bug
database. Thanks!

-Jay



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

Bad tuplet beam

[Jay Anderson]

I managed to simplify my test file to get a segfault with the following:

=
\version 2.11.16

\paper
{
 ragged-right = ##t
}

%57 - no segfault
%58 - segfault
spacer = { \repeat unfold 58 R2 }

\score
{
 \new PianoStaff
 
   \new Staff = RH
   {
 \time 2/4
 \clef treble
 \spacer
 r4 s |
 \spacer
   }
   \new Staff = LH
   \relative c'
   {
 \time 2/4
 \clef bass
 \spacer
 
   {
 \times 2/3 {bes8 bes bes}
 \change Staff=RH
 \times 2/3 {bes bes bes} |
   }
   \\
   {
 s4 \change Staff=LH r4 |
   }
 
 \spacer
   }
 
}
=

I usually got this:

GNU LilyPond 2.11.16
Processing `test.ly'
Parsing...
Interpreting music...
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][117]
Preprocessing graphical objects...Segmentation fault

But without changing the code I also got:

GNU LilyPond 2.11.16
Processing `test.ly'
Parsing...
Interpreting music...
[8][16][24][32][40][48][56][64][72][80][88][96][104][112][117]
Preprocessing graphical objects...ERROR: In procedure
ly:tuplet-bracket::calc-positions:
ERROR: Wrong type (expecting real number): ()

Really odd. I'm not sure what the difference was between the runs.

If you null out the 'spacer' variable you can see the beam for the
first set of triplets is misplaced (attached). Thanks!

-Jay


test.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: 2.11.15 debug help / detached beam

[Jay Anderson]

Hmm... I was using 2.11.15-1 on Fedora Core 6. With 2.11.15-2 I get
the same result (along with the pdf generation problem others have
reported). I was unclear with what I said. When I compile the complete
file, I get a segfault. When I skip the typesetting of those measures
I don't get the segfault. When I pulled them out and typeset them
alone I also didn't get a segfault, but I saw weird beaming behavior.
So I'm thinking that's the root cause. Attached is a picture generated
with 2.11.15-2. Thanks for the help!

-Jay

Note: I couldn't get --png to work:

Converting to PNG...GPL Ghostscript SVN PRE-RELEASE 8.56: Can't find
initialization file gs_init.ps.
GS exited with status: 256

On 2/2/07, Graham Percival [EMAIL PROTECTED] wrote:

Jay Anderson wrote:
 I'm getting this in a file that used to compile pre 2.11.15:

 Preprocessing graphical objects...
 programming error: no skylines for alignment-child

 continuing, cross fingers
 Segmentation fault

I can't reproduce this in 2.11.15-2 on OSX.  What version and OS are you
using?

  Here's as short as I could get it:

Thanks; it's ok if a segfault report is a bit longer than other bug
reports.  This example would be fine if it didn't work.  (are you sure
you pasted the right example in your message?)

Cheers,
- Graham



test.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

2.11.15 debug help / detached beam

[Jay Anderson]

I'm getting this in a file that used to compile pre 2.11.15:

Preprocessing graphical objects...
programming error: no skylines for alignment-child

continuing, cross fingers
Segmentation fault

I have the problem somewhat narrowed down to a couple of measures. Is
there a way I can make it spit out more information? I'm pretty sure
I've read something about this, but I couldn't find it. The verbose
flag doesn't give me anything extra in this part of the output.

In any case I've been using \set Score.skipTypesetting to narrow it
down. If I just do those measures by themselves I don't get a
segfault, but I do get weird results with a triplet and a slur where
the beam is detached above the slur. I tried this with normal eighth
notes, but they didn't cause this error. Here's as short as I could
get it:

\version 2.11.15

\paper
{
 ragged-right = ##t
}

\score
{
 \new PianoStaff
 
   \new Staff = RH
   {
 \time 2/4
 \clef treble
 r4 s |
   }
   \new Staff = LH
   \relative c
   {
 \time 2/4
 \clef bass
 
   {
 \times 2/3 {bes8( bes' ees}
 \change Staff=RH
 \times 2/3 {g ees' bes')} |
   }
   \\
   {
 s4 \change Staff=LH r4 |
   }
 
   }
 
}

Thanks!

-Jay


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

Text crescendo collision with dynamic

[Jay Anderson]

This didn't used to collide in previous versions of lilypond (the last I tried
this was in 2.9.24). I did a search through the bugs and didn't find anything
similar. Thanks.

-Jay

\version 2.11.14

\paper
{
  ragged-right = ##t
}

\new Staff
\relative c'
{
  \setTextCresc
  c4\p\ c c c\!
}




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

Arpeggio collision

[Jay Anderson]

I see that issue 10 is closed
(http://code.google.com/p/lilypond/issues/detail?id=10). However, I'm
still seeing similar behavior. The attached is from the actual score.
If I take out the accidentals it looks right. I can also remove the
acciacatura from the low voice to keep the arpeggio on the correct
side of the bar line. Let me know if there's anything else you want me
to do with this. Thanks!

-Jay

\version 2.11.13

\paper
{
 ragged-right = ##f
}

\new Staff
\relative c
{
 \time 6/8
 \key f \major
 \clef bass
 R2.*2 |
  {aes' ces f2.\arpeggio} \\ {\acciaccatura des,,8 \voiceTwo des2.}  |
 
   {
 des' ges bes des4.~\arpeggio des ges bes des8
   }
   \\
   {
 \acciaccatura ges,8 \voiceTwo ges4.~ ges8
   }
 
}


arpeggio-collision.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Crescendo extends too far.

[Jay Anderson]

In this example the crescendo extends to the end of the mark and no the bar line
as is usual. Take the mark out and it looks fine.

\version 2.11.11

\paper
{
  ragged-right = ##t
}

\new Staff
\relative c'
{
  c1\ |
  \mark Very long mark
  c4\ c c c\! |
}

-Jay



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

Segmentation fault 2.11.10

[Jay Anderson]

\version 2.11.10

\score
{
  \new Staff \relative c'''
  {
\time 2/4
bes e,4\fermata
  \grace {bes32[( a g fis g a bes c d c bes a g f e d c cis d a] c2)}
  bes e,4\fermata
  }
}

\layout
{
  ragged-right = ##t
}

I played around with it a bit and I don't get a seg fault when the last c2 is
changed to a solid note (like quarter or eighth), but I still get the seg fault
with a whole note. I also still got the seg fault when I changed the line to
bes32[ a] c2. Am I doing anything odd or wrong? Thanks!

-Jay Anderson



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

Re: clef collides with rest

[Jay Anderson]

Ok, here's what I've come up with to show the bug a little better:

-
\version 2.9.21

\score
{
 
   \new Staff
   {
 \relative c'
 {
   c4 c c c |
   c4 c8 c c4 c8 c |
   c8 c4 c8 c c4 c8 |
   c8 c c c c c c c |
   \times 2/3 {c4 c c} c4 c |
   c4 \times 2/3 {c4 c c} c4 |
   c4 c \times 2/3 {c4 c c} |
   \times 2/3 {c4 c c} \times 2/3 {c c c} |
 }
   }
   \new Staff
   {
 \repeat unfold 8 {\clef treble d''4 r \clef bass f r |}
   }
 
 \layout
 {
   indent = #0
   line-width = #30
 }
}

-

I know this is artifically compressing the systems, but it's the
closest I could get it to how lilypond formatted it automatically for
me in the real piece. In any case the bass clef is misplaced in
measures 3, 5, and 8. In the good measures the rest's position is
adjusted to make room for the clef while in these it is not.

I'll see if I can isolate the bad tie problem a bit later. Thanks again.

-Jay

On 10/6/06, Werner LEMBERG [EMAIL PROTECTED] wrote:


 By 'better' I meant that it shows the problem more clearly. I haven't
 tweaked much at all yet. This is default Lilypond and it doesn't
 complain one bit about it getting too dense:

The new image definitely classifies the collision as a bug.  It would
be great if you could extract a minimal example (probably by reducing
the line length), reducing it as much as possible.

BTW, there is another bug hidden in the image: the tie in the bass
line from the first to the second bar appears as a dot only.  This is
something serious...  According to your other mails I presume that you
already use the latest lilypond version.  Again I ask you to isolate
the problem to the smallest possible case.  I know that it is quite
time consuming, but it enormously increases the chances to get a quick
fix.

 I've done this to make it smaller:

 -
 \new Staff
 \with
{
   fontSize = #-3
   \override StaffSymbol #'staff-space = #(magstep -3)
 }
 {\hornNotes}
 -

 Is this not good practice?

This is fine, I think.


Werner



bug2a.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef collides with rest

[Jay Anderson]

Yeah, I agree that there wasn't a total collision in the examples I
provided. Perhaps the attached is a bit better. This is what is
created when I generate the whole file and not just a little snippet.
I tried to boil the example down as much as possible. There is
definitely a problem. I can point you to the whole file if needed.
Thanks!

-Jay Anderson

On 10/6/06, Graham Percival [EMAIL PROTECTED] wrote:

Werner LEMBERG wrote:
 The bass clef in the following example collides with the rest in
 the following example. It looks worse in context than it does
 here, but normally lilypond does a good job of spacing the clef
 changes. Is there any tweak I can do to fix this or are there
 deeper problems?  Thanks for the help.

 IMHO the output is bad, and lilypond should be able to handle this
 automatically -- clef changes in similar situations occur far too
 frequently in classical music.

OK, I've added it, but this is probably a long-term wishlist item.
http://code.google.com/p/lilypond/issues/detail?id=110

Cheers,
- Graham



collision.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: clef collides with rest

[Jay Anderson]

By 'better' I meant that it shows the problem more clearly. I haven't
tweaked much at all yet. This is default Lilypond and it doesn't
complain one bit about it getting too dense:

-
Processing `E:/cygwin/home/Jay/open-scores/DukasVillanelle/trunk/Piano.ly'
Parsing...
Interpreting music... [8][16][24][32][40][48][56][64][72][80]
E:/cygwin/home/Jay/open-scores/DukasVillanelle/trunk/PianoNotes.lyi:452:12:
warning: Ignoring grob for slur. avoid-slur not set?
   { c''4-.
   -^( bes' g2~) | bes g4 }
E:/cygwin/home/Jay/open-scores/DukasVillanelle/trunk/PianoNotes.lyi:452:12:
warning: Ignoring grob for slur. avoid-slur not set?
   { c''4-.
   -^( bes' g2~) | bes g4 }
E:/cygwin/home/Jay/open-scores/DukasVillanelle/trunk/PianoNotes.lyi:452:12:
warning: Ignoring grob for slur. avoid-slur not set?
   { c''4-.
   -^( bes' g2~) | bes g4 }
E:/cygwin/home/Jay/open-scores/DukasVillanelle/trunk/PianoNotes.lyi:457:10:
warning: Ignoring grob for slur. avoid-slur not set?
   { c4-.
 -^( bes' g2~) | bes g1~ | bes g4 }[88][96][104]
E:/cygwin/home/Jay/open-scores/DukasVillanelle/trunk/PianoNotes.lyi:483:14:
warning: Ignoring grob for slur. avoid-slur not set?
 a d,1~
 -^)
|[112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232][240][248][256][264][272][280][288][296][302]
Preprocessing graphical objects...
programming error: no heads for arpeggio found?
continuing, cross fingers
programming error: no heads for arpeggio found?
continuing, cross fingers
Layout output to `Piano.ps'...
Converting to `Piano.pdf'...
-

Only a few warnings about marcato marks and arpeggios. It may be
getting too dense because of the horn part. I've done this to make it
smaller:

-
   \new Staff
   \with
  {
 fontSize = #-3
 \override StaffSymbol #'staff-space = #(magstep -3)
   }
   {\hornNotes}
-

Is this not good practice? Is there a way I can spread it out a bit?
I'm not quite sure how to remove a bar from the system without adding
in manual \breaks. I did this and had to take out about 5 measures
from the system to make it look nicer. Even then the bass clef is
right on top of the rest. I'll play with it a bit more when I'm done
entering the notes of the piece to make it presentable. Thanks for the
help again. (You guys are quick. I'm always surprised at how
responsive you all are.)

-Jay


On 10/6/06, Werner LEMBERG [EMAIL PROTECTED] wrote:


 Yeah, I agree that there wasn't a total collision in the examples I
 provided. Perhaps the attached is a bit better.

It's not really better.  The music is typeset far too densely.  I'm
quite sure that lilypond complains about it.  What about removing,
say, the first bar so that the system is dense but not overfull?  Does
this still cause a collision?


Werner



collision.png
Description: PNG image
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond

partcombine status

[Jay Anderson]

After making this example for the bug report I did a quick search for
the problems I was seeing. I'm having trouble with the partcombiner
and it seems that it is being rewritten (from Han-Wen Nienhuys on
2005-08-20). I'm just wondering if there is any status on this effort?
(side question: is there a bug tracker setup for lilypond for looking
up status on these issues? bugzilla, mantis, trac, etc.?) I started
looking through the code to understand it, but if there is already an
effort to fix it I'll hold off.

The problems I'm seeing are well known from what it looks like:

- Blank measures, missing rests.
- Parts are not combined when more than an octave apart.

This second one apparently is the intended behavior. Is there any way
to disable this (or a hack to get around it)? For my purposes it is
really NOT what I want.

Below are examples of what I'm seeing. The first has a blank 7th
measure and is missing a rest in the first part of the next measure
(I'm not sure I've seen this second missing rest reported before) The
second example is just parts being more than an octave apart. The only
solution that I've come up with so far is using lots of tags to take
out some of the dynamics when I generate the score; a pain and still
not quite what I'm wanting.

Thanks for all the help!

-Jay Anderson

\version 2.8.3

clarinetOne = \relative c''
{
 \time 3/4
 \key f \major
 r4 r c~\p |
 c(_\markup{\italic cresc.} d ees) |
 f2(\p a4 |
 f2 c4) |
 f( a c |
 f,) r r |
 R2. |
 r4 r a,(\p |
 bes d f) |
}

clarinetTwo = \relative c''
{
 \time 3/4
 \key f \major
 R2.*9 |
}

hornOne = \relative c''
{
 \time 3/4
 \key c \major
 r4 d2~\f |
 d4 d2~\f |
 d4 d2\f |
 d2\f d4-.\f |
 d4-. f-.\ff \repeat unfold 10 {f-.} |
 e4 r r |
 e r r |
 c r r | \bar |.
}

hornTwo = \relative c'
{
 \time 3/4
 \key c \major
 r4 g2~\f |
 g4 g2~\f |
 g4 g2\f |
 g2\f g4-.\f |
 g4-. g-.\ff \repeat unfold 10 {g-.} |
 c4 r r |
 c' r r |
 e, r r | \bar |.
}

\score
{
 \new Staff
 {
   \set Staff.instrument = Clarinets
   \set Staff.instr = Cl.
   \partcombine
 \clarinetOne
 \clarinetTwo
 }
}

\score
{
 \new Staff
 {
   \set Staff.instrument = Horns
   \set Staff.instr = Hn.
   \partcombine
 \hornOne
 \hornTwo
 }
}


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