Re: Issue 1799 in lilypond: output-distance.py does not parse scheme nan values correctly
Comment #1 on issue 1799 by mts...@gmail.com: output-distance.py does not parse scheme nan values correctly http://code.google.com/p/lilypond/issues/detail?id=1799 It seems that my patch fixes the problem - I applied it to the branch where I'm running my stem regtests, and now the regtests compile clean and give me out/test-results/index.html . Cheers, MS ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1776 in lilypond: Doc: NR - Polymetric Notation \compoundMeter isn't documented
Comment #11 on issue 1776 by lemniska...@gmail.com: Doc: NR - Polymetric
Notation \compoundMeter isn't documented
http://code.google.com/p/lilypond/issues/detail?id=1776
James,
i hoped to answer sooner but i had to fight problems with grand-fixcc.
2011/7/31 Comment #9 on issue 1776 by pkx166h:
However, because I am curious (and don't a thing about this special
notation) can you tell me why
\relative c' {
\compoundMeter #'((1 4) (3 8 4))
\repeat unfold 5 c8 \repeat unfold 10 c16
}
This one is perfectly ok and compiles for me.
\relative c' {
\compoundMeter #'((2) (3 8 4))
\repeat unfold 5 c8 \repeat unfold 10 c16
}
You cannot have only one number in parentheses.
Fails? and why I get a different error for each case?
Id kind of expect
\compoundMeter #'((2) (3 8 4))
to be equiv of 2
3 + 8 + 4
Is this not allowed in music?
Or at the very least 2 + 2 + 2
3 8 4
Maybe this is an enhancement?
Again as an example
\compoundMeter #'((1 4) (3 8 4))
could be the same as 1 + 4 + 4
3 8 4
I hope this makes sense?
I'm afraid not... It looks like you're reading the syntax in the wrong
way. I'll try to explain it in more detail (hoping that i understand it
correctly myself ;).
Time signature tells musicians how many beats are in the measure and what
is their length. Ordinary time signature is like a fraction: \time 3/4
says "there are three beats in the measure, each beat has a length of a
quarter note", \time 8/8 says "there are eight beats in the measure, each
beat has a length of an eight note" and so on: the numerator of the
fraction says how many beats are in the measure, and the denominator says
how long they are.
Now consider a piece written in 15/8 (this surely is a strange meter!). It
tells that there are 15 eight notes in the measure, but how the musician is
supposed to play it - how will he subdivide the measure? (for example, a
6/8 measure is divided into two groups, each consisting of 3 eight notes:
*one* two three *one* two three). What is the composer's intention in
case of 15/8? That's where \compoundMeter comes to rescue: one can write
\compoundMeter #'((4 4 4 3 8)) and the musician will know that he should
play it like this:
*one* two three four *one* two three four *one* two three four *one* two
three
writing \compoundMeter #'((3 3 3 3 3 8)) would mean to play it like this:
*one* two three *one* two three *one* two three *one* two three *one*
two three
Now imagine a meter in which beats have different length. For example,
first beat in the measure is a quarter note, and second beat is a half
note. How are you supposed to write this? The measure length is 1 quarter
+ 1 half = 3 quarter notes, but you cannot write \time 3/4 because that
means "three beats, each one quarter long". \compoundMeter #'((1 2 4))
wouldn't be accurate, too. You need to write this time signature as 1/4 +
1/2 - this is accomplished with \compoundMeter #'((1 4) (1 2)) .
So, using the "fraction" nomenclature, \compoundMeter #'((2 3 4)) produces
a single fraction (with the numerator consisting of two numbers: 2 and 3),
while \compoundMeter #'((3 8) (2 4)) produces two fractions (3/8 and 2/4).
Notice where the plus sign is located in each case. As you can see, each
parentheses inside \compoundMeter #'( ) corresponds to a separate fraction
in the final time signature; \compoundMeter #'((3 8) (1 2) (4 1 4)) will be
made of 3 fractions. If you write \compoundMeter #'((2) (3 8 4)), you are
telling Lily "do a complex meter consisting of two fractions: first
fraction will be made from number 2, second fraction will be made from
numbers 3, 8 and 4" - while one number (2) is not enough to form a
fraction: at least two numbers are necessary for a fraction!
Maybe it would be good to include some of this explanation in the patch?
I just want to know what the limitations there are and if these are
@knownissues or bugs or something else I need to document.
I thought i found one, but now it seems to works... It seemed that
\compoundMeter wouldn't accept irrational meters (for example
\compoundMeter #'((1 3) (1 4)) ), but now it works... Strange.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
[2.14.2] cadenzaOn makes [ ] behave like ( ) with regards to lyrics (regression vs 2.12)
In the following code, no word is placed below the second eight note.
Commenting \cadenzaOn or removing manual beaming [] works fine.
Manual beaming [ ] behaves like slur ( ).
This worked in previous versions.
\version "2.14.0"
\score {
<<
\context Voice = "notes" \relative {
\cadenzaOn
c1 c8[ c8] c2. \bar "|" \break
\cadenzaOff
}
\lyricsto "notes" \new Lyrics { one two three four }
>>
}
Frédéric
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1800 in lilypond: Segfault compiling LSR 346
Comment #1 on issue 1800 by k-ohara5...@oco.net: Segfault compiling LSR 346
http://code.google.com/p/lilypond/issues/detail?id=1800
% Tinyfying the example leads us to cross staff beams
%
\score { <<
{ \context Staff = "up" c8 c %\noBeam % noBeam prevents segfault
\change Staff = "down" c c
}
\context Staff = "down" { s1 }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Ugly collision between broken Slur and PhrasingSlur
On 11-08-02 10:05 AM, Urs Liska wrote:
Hi,
following the late discussions on bug- and -user, I stumbled over an
ugly collision between a phrasingSlur and a Slur at the beginning of a
second staff. Actually the phrasing slur tries to escape the slur but
does this in a spectacular way - while the collision is still there:
\version "2.15.5"
\relative a'
{
\key d \major
\time 2/2
\clef treble
a2.\(( d8[ cis] | \break
b2 cis4) b\) | \break
a2.\((\p d8[ cis] | \break
b2.) cis4\) | \break
}
The breaks are needed because in the real example there are many notes
in the piano ...
In lines 1 and 2 it is only an ugly collision (probably an instance of
issue #427?)
but lines 3 and 4 (when the slur ends on the first note after the line
break) are really crazy and mess up the page layout of my music
completely.
Is this just issue #427 or should one add a new issue?
If not, what about the fact that #427 is abandonde?
I think this is quite an embarassing output.
Best
Ur
It certainly does look like issue 427, Urs, although the slur in bar 4
is rather remarkable! The issue is still open, but a proposed patch was
marked abandoned in February, as the developer was no longer working on
the issue. Issue 163 is also quite similar, and Mike Solomon has a patch
in progress which looks like it should fix the problem.
Cheers,
Colin Campbell
Bug Squad
--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crashes when compiling snippet
On 11-08-02 04:15 PM, David Kastrup wrote: James Lowe writes: From: lilypond-user-bounces+james.lowe=datacore@gnu.org [lilypond-user-bounces+james.lowe=datacore@gnu.org] on behalf of Tim Reeves [tim.ree...@tokamerica.com] Sent: 02 August 2011 19:56 To: lilypond-u...@gnu.org Subject: Lilypond crashes when compiling snippet I tried to compile the "Creating music with Scheme (music box)" snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=346 ) and when I do, Lilypond crashes [...] Now all that said I have also run this on latest version from the current tree (2.15.9) from tonight and I get a seg fault while compiling. Looks like the autobeamer. Mike? (gdb) bt #0 0x080d4794 in Context::get_parent_context (this=0x0) at context.cc:685 #1 0x080ed2bf in Engraver_group::announce_grob (this=0x860c1d8, info=...) at engraver-group.cc:73 #2 0x080ed322 in Engraver_group::announce_grob (this=0x860d460, info=...) at engraver-group.cc:86 #3 0x0806d541 in Auto_beam_engraver::create_beam (this=0x860dc28) at auto-beam-engraver.cc:225 #4 0x0806db45 in Auto_beam_engraver::end_beam (this=0x860dc28) at auto-beam-engraver.cc:272 #5 0x0806def0 in Auto_beam_engraver::consider_end (this=0x860dc28, test_mom=..., dur=...) at auto-beam-engraver.cc:200 #6 0x0806e1e3 in Auto_beam_engraver::process_acknowledged (this=0x860dc28) at auto-beam-engraver.cc:516 #7 0x082a7581 in invoke (this=0x860d478, idx=PROCESS_ACKNOWLEDGED) at ./include/translator-group.hh:46 #8 Translator_group::precomputed_translator_foreach (this=0x860d478, idx=PROCESS_ACKNOWLEDGED) at translator-group.cc:325 #9 0x080ed125 in Engraver_group::do_announces (this=0x860d460) at engraver-group.cc:175 #10 0x080ed0ef in Engraver_group::do_announces (this=0x8606468) at engraver-group.cc:169 #11 0x080ed0ef in Engraver_group::do_announces (this=0x86038f0) at engraver-group.cc:169 #12 0x080ed0ef in Engraver_group::do_announces (this=0x857e818) at engraver-group.cc:169 #13 0x0820da51 in one_time_step (self=0x857e818, ev=0xb5a2f640) at score-engraver.cc:152 #14 Score_engraver::one_time_step_callback (self=0x857e818, ev=0xb5a2f640) at score-engraver.cc:145 #15 0x080dd16c in Dispatcher::dispatch (this=0x857c440, sev=0xb5a2f640) at dispatcher.cc:150 #16 0x080d2a07 in Context::internal_send_stream_event (this=0x857cfc4, type=0xb7187d00, origin=0x0, props=0xbfffc90c) at context.cc:461 #17 0x0811332c in Global_context::run_iterator_on_me (this=0x857cf60, iter=0x857d570) at global-context.cc:170 #18 0x08111d04 in ly_interpret_music_expression (mus=0x857cf60, ctx=0xb73a6f68) at global-context-scheme.cc:119 #19 0x08112106 in ly_run_translator (mus=0xb78d3188, output_def=0xb73a6f68) at global-context-scheme.cc:147 #20 0x08212a0e in Score::book_rendering (this=0x85fba68, layoutbook=0x85923d8, default_def=0x849a8e0) at score.cc:157 #21 0x080a14a4 in Book::process_score (this=0x858f108, s=0xb73b50d8, output_paper_book=0x857c550, layout=0x849a8e0) at book.cc:236 #22 0x080a16cc in Book::process (this=0x858f108, default_paper=0x847ef18, default_layout=0x849a8e0, parent_part=0x0) at book.cc:302 #23 0x080a18e7 in Book::process (this=0x858f108, default_paper=0x847ef18, default_layout=0x849a8e0) at book.cc:207 #24 0x0809e9d3 in ly_book_process (book_smob=0xb73c8910, default_paper=0xb7b69040, default_layout=0xb7a6e6b8, output=0xb7138210) at book-scheme.cc:76 #25 0x0018041b in scm_gsubr_apply () from /usr/lib/libguile.so.17 #26 0x0016c979 in scm_apply () from /usr/lib/libguile.so.17 #27 0x00169fc1 in ?? () from /usr/lib/libguile.so.17 #28 0x0016e2cb in scm_primitive_eval () from /usr/lib/libguile.so.17 #29 0x081d409a in ly_parse_scm (s=0x844e660 "(let ((book-handler (if (defined? 'default-toplevel-book-handler)\n", ' ', "default-toplevel-book-handler\n", ' ', "toplevel-book-handler)))\n (cond ((pair? toplevel-boo"..., n=0xbfffce28, i=..., safe=false, parser=0x8502440) at parse-scm.cc:139 #30 0x082c9d9e in Lily_lexer::yylex (this=0x8407cf8) at lexer.ll:353 #31 0x082cd2a6 in yylex (my_lily_parser=0x8502440) at parser.yy:2784 #32 yyparse (my_lily_parser=0x8502440) at out/parser.cc:2486 #33 0x0814d9a8 in Lily_parser::parse_file (this=0x8502440, init=Cannot access memory at address 0x0 ) at lily-parser.cc:121 #34 0x0814b419 in ly_parse_file (name=0xbfffe760) at lily-parser-scheme.cc:123 #35 0x0016a975 in ?? () from /usr/lib/libguile.so.17 #36 0x0016e00b in scm_call_0 () from /usr/lib/libguile.so.17 #37 0x001cc06e in scm_body_thunk () from /usr/lib/libguile.so.17 #38 0x001cc2f3 in scm_c_catch () from /usr/lib/libguile.so.17 #39 0x001cc532 in scm_catch_with_pre_unwind_handler () from /usr/lib/libguile.so.17 #40 0x0018041b in scm_gsubr_apply () from /usr/lib/libguile.so.17 #41 0x0016c979 in scm_apply () from /usr/lib/libguile.so.17 #42 0x00169fc1 in ?? () from /usr/lib/libguile.so.17 #43 0x0016a416 in ?? () from /usr/lib/libguile.so.17 #44 0x0016ec28 in ?? () from /usr/lib/libguile.so.17 #45 0x008abd9c in scm_srfi1_for_each () from /usr/lib/libguile-srfi-sr
Issue 1800 in lilypond: Segfault compiling LSR 346
Status: Accepted Owner: Labels: Type-Defect Priority-Critical New issue 1800 by colinpkc...@gmail.com: Segfault compiling LSR 346 http://code.google.com/p/lilypond/issues/detail?id=1800 User Tim Reeves (tim.ree...@tokamerica.com) reports: I tried to compile the "Creating music with Scheme (music box)" snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=346 ) and when I do, Lilypond crashes with the following output: > %lilypond %args "C:\Documents and Settings\timr\Desktop\Bach Prelude in C major.ly" Processing `C:/Documents and Settings/timr/Desktop/Bach Prelude in C major.ly' Parsing... Interpreting music... [8][16][24][32] Processing time: 4 seconds So it seems to get through compiling except it fails to generate the ps or pdf. Any idea why? I should add: I didn't know what version to tell Lilypond the snippet was, so I assumed the previous stable version, 2.12.3. Is that correct? (LP 2.15.1 on Windows XP SP3) ** On my machine (Ubuntu 11.04 x86-64), it compiled w/no errors under 2.12 and segfaults for both 2.14.2 D/L today and 2.15.3, although James L reports success with 2.14.1 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1799 in lilypond: output-distance.py does not parse scheme nan values correctly
Status: Accepted
Owner:
Labels: Type-Build Priority-High Patch-new
New issue 1799 by mts...@gmail.com: output-distance.py does not parse
scheme nan values correctly
http://code.google.com/p/lilypond/issues/detail?id=1799
nan values in scheme are issued as +nan.0 and -nan.0, which Python doesn't
understand. This patch at fixes the parsing, although I'm not sure if
other parts of output-distance.py are not nan friendly as well (and I
wouldn't know how to check how it handles nan once nan is parsed - someone
who knows output-distance.py better than I would need to help me
understand what type of input it expects). The issue creeped up when I was
running regtests on a patch.
Patch at http://codereview.appspot.com/4835049/
I'm marking this as high priority, but it could be considered critical
insofar as it will always crash the build system when +nan.0 or -nan.0 is
encountered.
Original problem from:
Traceback (most recent call last):
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
1261, in
main ()
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
1258, in main
compare_tree_pairs (zip (args[0::2], args[1::2]), out,
options.threshold)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
970, in compare_tree_pairs
data.compare_trees (dir1, dir2)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
810, in compare_trees
self.compare_directories (dir1, dir2)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
841, in compare_directories
self.compare_files (f1, f2)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
845, in compare_files
self.compare_signature_files (f1, f2)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
877, in compare_signature_files
file_link.add_file_compare (f1, f2)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
596, in add_file_compare
s2 = read_signature_file (f2)
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
331, in read_signature_file
if e and not e.startswith ('#')]
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
325, in string_to_entry
fields[2] = string_to_tup (fields[2])
File "/home/mikesol/lilypond-reg/scripts/build/out/output-distance", line
321, in string_to_tup
return tuple (map (float, s.split (' ')))
ValueError: invalid literal for float(): +nan.0
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1776 in lilypond: Doc: NR - Polymetric Notation \compoundMeter isn't documented
Updates: Labels: -Frog Patch-review Comment #10 on issue 1776 by pkx1...@gmail.com: Doc: NR - Polymetric Notation \compoundMeter isn't documented http://code.google.com/p/lilypond/issues/detail?id=1776 Patch for doc here http://codereview.appspot.com/4837050 I'd still like the above points in the last comment clarified (if only to improve the documentation). James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crashes when compiling snippet
On Aug 2, 2011, at 11:15 PM, David Kastrup wrote: > James Lowe writes: > >> From: lilypond-user-bounces+james.lowe=datacore@gnu.org >> [lilypond-user-bounces+james.lowe=datacore@gnu.org] on behalf of >> Tim Reeves [tim.ree...@tokamerica.com] >> Sent: 02 August 2011 19:56 >> To: lilypond-u...@gnu.org >> Subject: Lilypond crashes when compiling snippet > >>> I tried to compile the "Creating music with Scheme (music box)" >>> snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=346 ) and when I do, >>> Lilypond crashes > > [...] > >> >> Now all that said I have also run this on latest version from the >> current tree (2.15.9) from tonight and I get a seg fault while >> compiling. > > Looks like the autobeamer. Mike? > As I have never worked on the auto-beam engraver, I think the fix would go faster if someone more familiar with it took it on. I would be happy to, though, if no one has time. I will say, though, that I am putting the finishing touches on the first draft of a set of .ly files called "lazy-lily" that I'll post on github soon. It is a suite of music functions that makes certain pre-engraver decisions. Right now, it has: \lazyMultiMeasureRests turns all full-measure rests into multi-measure rests \lazyUnslurRests slurs that cross over a rest are cut: ie a ( b c r r d e r f r ) becomes a ( b c ) r r d ( e ) r f r I'm currently working on \lazyUntie, which turns anything like a32-| ~ a32 into a32-| r32. Afterwards, I'll be working on \lazyProlation, which is like the completion notes/heads engraver on steroids (automatically groups and/or breaks notes and rests depending on their place in the measure and/or tuplet). The auto-beam-engraver can and should be implemented more along these lines (\lazyAutoBeaming, which inserts beam events into the stream). Of course, the problem at hand could have nothing to do with anything I say above, but I figured I'd mention it, as it is related to something that's been in my mind. In general, it'd be great if all grobs were acknowledgeable (made using make_item or make_spanner) during the timestep when their causing event/grob is issued, and conditioning the event stream with lazy functions is a way to make this happen. Cheers, MS ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond crashes when compiling snippet
James Lowe writes: > From: lilypond-user-bounces+james.lowe=datacore@gnu.org > [lilypond-user-bounces+james.lowe=datacore@gnu.org] on behalf of > Tim Reeves [tim.ree...@tokamerica.com] > Sent: 02 August 2011 19:56 > To: lilypond-u...@gnu.org > Subject: Lilypond crashes when compiling snippet >> I tried to compile the "Creating music with Scheme (music box)" >> snippet ( http://lsr.dsi.unimi.it/LSR/Item?id=346 ) and when I do, >> Lilypond crashes [...] > > Now all that said I have also run this on latest version from the > current tree (2.15.9) from tonight and I get a seg fault while > compiling. Looks like the autobeamer. Mike? (gdb) bt #0 0x080d4794 in Context::get_parent_context (this=0x0) at context.cc:685 #1 0x080ed2bf in Engraver_group::announce_grob (this=0x860c1d8, info=...) at engraver-group.cc:73 #2 0x080ed322 in Engraver_group::announce_grob (this=0x860d460, info=...) at engraver-group.cc:86 #3 0x0806d541 in Auto_beam_engraver::create_beam (this=0x860dc28) at auto-beam-engraver.cc:225 #4 0x0806db45 in Auto_beam_engraver::end_beam (this=0x860dc28) at auto-beam-engraver.cc:272 #5 0x0806def0 in Auto_beam_engraver::consider_end (this=0x860dc28, test_mom=..., dur=...) at auto-beam-engraver.cc:200 #6 0x0806e1e3 in Auto_beam_engraver::process_acknowledged (this=0x860dc28) at auto-beam-engraver.cc:516 #7 0x082a7581 in invoke (this=0x860d478, idx=PROCESS_ACKNOWLEDGED) at ./include/translator-group.hh:46 #8 Translator_group::precomputed_translator_foreach (this=0x860d478, idx=PROCESS_ACKNOWLEDGED) at translator-group.cc:325 #9 0x080ed125 in Engraver_group::do_announces (this=0x860d460) at engraver-group.cc:175 #10 0x080ed0ef in Engraver_group::do_announces (this=0x8606468) at engraver-group.cc:169 #11 0x080ed0ef in Engraver_group::do_announces (this=0x86038f0) at engraver-group.cc:169 #12 0x080ed0ef in Engraver_group::do_announces (this=0x857e818) at engraver-group.cc:169 #13 0x0820da51 in one_time_step (self=0x857e818, ev=0xb5a2f640) at score-engraver.cc:152 #14 Score_engraver::one_time_step_callback (self=0x857e818, ev=0xb5a2f640) at score-engraver.cc:145 #15 0x080dd16c in Dispatcher::dispatch (this=0x857c440, sev=0xb5a2f640) at dispatcher.cc:150 #16 0x080d2a07 in Context::internal_send_stream_event (this=0x857cfc4, type=0xb7187d00, origin=0x0, props=0xbfffc90c) at context.cc:461 #17 0x0811332c in Global_context::run_iterator_on_me (this=0x857cf60, iter=0x857d570) at global-context.cc:170 #18 0x08111d04 in ly_interpret_music_expression (mus=0x857cf60, ctx=0xb73a6f68) at global-context-scheme.cc:119 #19 0x08112106 in ly_run_translator (mus=0xb78d3188, output_def=0xb73a6f68) at global-context-scheme.cc:147 #20 0x08212a0e in Score::book_rendering (this=0x85fba68, layoutbook=0x85923d8, default_def=0x849a8e0) at score.cc:157 #21 0x080a14a4 in Book::process_score (this=0x858f108, s=0xb73b50d8, output_paper_book=0x857c550, layout=0x849a8e0) at book.cc:236 #22 0x080a16cc in Book::process (this=0x858f108, default_paper=0x847ef18, default_layout=0x849a8e0, parent_part=0x0) at book.cc:302 #23 0x080a18e7 in Book::process (this=0x858f108, default_paper=0x847ef18, default_layout=0x849a8e0) at book.cc:207 #24 0x0809e9d3 in ly_book_process (book_smob=0xb73c8910, default_paper=0xb7b69040, default_layout=0xb7a6e6b8, output=0xb7138210) at book-scheme.cc:76 #25 0x0018041b in scm_gsubr_apply () from /usr/lib/libguile.so.17 #26 0x0016c979 in scm_apply () from /usr/lib/libguile.so.17 #27 0x00169fc1 in ?? () from /usr/lib/libguile.so.17 #28 0x0016e2cb in scm_primitive_eval () from /usr/lib/libguile.so.17 #29 0x081d409a in ly_parse_scm (s=0x844e660 "(let ((book-handler (if (defined? 'default-toplevel-book-handler)\n", ' ' , "default-toplevel-book-handler\n", ' ' , "toplevel-book-handler)))\n (cond ((pair? toplevel-boo"..., n=0xbfffce28, i=..., safe=false, parser=0x8502440) at parse-scm.cc:139 #30 0x082c9d9e in Lily_lexer::yylex (this=0x8407cf8) at lexer.ll:353 #31 0x082cd2a6 in yylex (my_lily_parser=0x8502440) at parser.yy:2784 #32 yyparse (my_lily_parser=0x8502440) at out/parser.cc:2486 #33 0x0814d9a8 in Lily_parser::parse_file (this=0x8502440, init=Cannot access memory at address 0x0 ) at lily-parser.cc:121 #34 0x0814b419 in ly_parse_file (name=0xbfffe760) at lily-parser-scheme.cc:123 #35 0x0016a975 in ?? () from /usr/lib/libguile.so.17 #36 0x0016e00b in scm_call_0 () from /usr/lib/libguile.so.17 #37 0x001cc06e in scm_body_thunk () from /usr/lib/libguile.so.17 #38 0x001cc2f3 in scm_c_catch () from /usr/lib/libguile.so.17 #39 0x001cc532 in scm_catch_with_pre_unwind_handler () from /usr/lib/libguile.so.17 #40 0x0018041b in scm_gsubr_apply () from /usr/lib/libguile.so.17 #41 0x0016c979 in scm_apply () from /usr/lib/libguile.so.17 #42 0x00169fc1 in ?? () from /usr/lib/libguile.so.17 #43 0x0016a416 in ?? () from /usr/lib/libguile.so.17 #44 0x0016ec28 in ?? () from /usr/lib/libguile.so.17 #45 0x008abd9c in scm_srfi1_for_each () from /usr/lib/libguile-srfi-srfi-1-v-3.so #46
Re: Issue 1267 in lilypond: Documentation for 'ignore-collision is unclear
Comment #3 on issue 1267 by pkx1...@gmail.com: Documentation for 'ignore-collision is unclear http://code.google.com/p/lilypond/issues/detail?id=1267 OK we need some clarification here. The 'reference in the NR' that I can find (but is not really indicated in the message thread) is in Appendix 15 and so there is no snippet associated with this. The LSR is not 'documentation', so while I have no problems with the LSR snippet being changed (I do not have permissions to change an snippet else I'd do it myself), do we still need to change the note in the Appendix as this seems ok in the context of the Appendix? The LSR snippet is not (at least as far as I can see) included in the NR anywhere. If you think we need more explanation that either an LSR entry or the Appendix then can you suggest where this would go and what kind of thing you want? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1779 in lilypond: accidentaled notes too far from the barline
Updates: Labels: -Patch-review Patch-needs_work Comment #7 on issue 1779 by lemniska...@gmail.com: accidentaled notes too far from the barline http://code.google.com/p/lilypond/issues/detail?id=1779 I see two probably problematic regtests; their output is attached. note-head-chord - while i generally like the idea of suspended noteheads being treated like 'decoration' (i.e. getting less space between it and the barline than a normal, bare notehead would get), i have an impression it's gone a bit too far in this case. predefined-fretboards-transpose - chord diagrams look definately too crowded now. Attachments: note-head-chord-current.pdf 22.8 KB note-head-chord-new.pdf 22.7 KB predefined-fretboards-transpose-current.pdf 70.5 KB predefined-fretboards-transpose-new.pdf 70.6 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1793 in lilypond: Doc: change how lyrics in PianoStaff is documented
Comment #2 on issue 1793 by pkx1...@gmail.com: Doc: change how lyrics in PianoStaff is documented http://code.google.com/p/lilypond/issues/detail?id=1793 I looked at the section and while Trevor says to remove the first example, this would also require a re-write of the para before, however as this is about aligning contexts would it be appropriate perhaps to use a different context (i.e. not lyrics) to still show the comparison? I just don't have any ideas for what would be useful at this point. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1775 in lilypond: doc: add broken- and unbroken slur shaping function
Comment #8 on issue 1775 by pkx1...@gmail.com: doc: add broken- and unbroken slur shaping function http://code.google.com/p/lilypond/issues/detail?id=1775 Hello, please find PDF attached of most recent 2.15.9 output - bearing in mind that the LSR is still at 2.12.x and the ly file contains a 2.13.x version number. Is this what I should expect as output? Attachments: test.pdf 26.2 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1796 in lilypond: LilyPond segfaults on make-footer = ##f
Updates: Labels: -Patch-new Patch-review Comment #1 on issue 1796 by pkx1...@gmail.com: LilyPond segfaults on make-footer = ##f http://code.google.com/p/lilypond/issues/detail?id=1796 Passes make and reg tests. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Full measure rest should take more horizontal space
2011/8/2 Xavier Scheuer : > 2011/7/31 Janek Warchoł : >> >> Wow, i'm CCed! Why? > > You are on my list as aesthetic guru (+ good engraving practices). OMG! That's an honour, thanks! > And also because Gmail's "Consider including" feature suggested me to > Cc you (and finally because it usually makes the person reply to the > message, which is good in order to hear its opinions). True indeed, at least in my case :) cheers, Janek ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1742 in lilypond: print transposed guitar chords on piano sheets
Comment #7 on issue 1742 by lemniska...@gmail.com: print transposed guitar chords on piano sheets http://code.google.com/p/lilypond/issues/detail?id=1742 I've merged Wol's patches with c++ style formatting changes and ran regtests again from scratch: everything is still fine. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 746 in lilypond: Automatic code indentation improvement (and replacing tabs with spaces)
Updates: Status: Fixed Labels: fixed_2_15_8 Comment #13 on issue 746 by percival.music.ca: Automatic code indentation improvement (and replacing tabs with spaces) http://code.google.com/p/lilypond/issues/detail?id=746 This has been resolved in GOP-PROP 4: C++ formatting. The fixcc.py script has been modified to use astyle 2.02, and it was run on all the source code on 2011 Aug 01. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Updates: Status: Fixed Labels: fixed_2_15_7 Comment #25 on issue 1663 by philehol...@googlemail.com: Images missing on web site http://code.google.com/p/lilypond/issues/detail?id=1663 Um. Following a link to a page that shouldn't even be there - one from 2.13 - isn't really a test. Try looking at the latest page that should have this image: http://lilypond.org/doc/v2.15/Documentation/web-big-page.html. I can see pictures. So this issue is fixed. I strongly believe we should close this issue and potentially open another to fix the problems with "make website" - but agree what this make option should _actually do_. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Comment #24 on issue 1663 by percival.music.ca: Images missing on web site http://code.google.com/p/lilypond/issues/detail?id=1663 first: when I follow the link in comment 1, I do not see pictures. I think that's the final test of whether this is done or not? second: I took a longer look at 6.2, and it is much less clear than I thought it was. My apologies. Relative to your choices in comment 19, I would say to use option 2a: the build system already copies the pictures and css, but in a relatively fragile manner (which was never intended to work for the big-html website anyway). The hints on this page: http://lilypond.org/doc/v2.15/Documentation/contributor/uploading-and-security are: """ Upload latest pictures/ and ly-examples/ (local script): Note: You may need to change a number of items in the below script. ... rsync -a $PICS gra...@lilypond.org:lilypond/media/pictures rsync -a $EXAMPLES gra...@lilypond.org:lilypond/media/ly-examples """ (rsync is a command that copies files, generally to a remote system but it can also be used locally. This puts pictures and examples in the $HOME/lilypond/media/.../ directories on lilypond.org, but you could use a similar command to put them in your own home directory) """ Build the website: ... make -f website.make WEBSITE_ONLY_BUILD=1 website """ the official website is not built with: make website alone, but instead with that WEBSITE_ONLY_BUILD=1 option. At the very top of make/website.make you see: # SECURITY -- check these values for lilypond.org # ifeq ($(WEBSITE_ONLY_BUILD),1) ### for lilypond.org ... EXAMPLES=$(HOME)/lilypond/media/ly-examples PICTURES=$(HOME)/lilypond/media/pictures else ### for normal git ... # I assume this is run from top-build-dir EXAMPLES=Documentation/web/ly-examples/out-www PICTURES=Documentation/pictures/out-www endif website.make also contains: website-pictures: mkdir -p $(OUT)/website/pictures if [ -d $(PICTURES) ]; \ then \ cp $(PICTURES)/* $(OUT)/website/pictures ; \ ln -sf website/pictures $(OUT)/pictures ;\ fi website-examples: mkdir -p $(OUT)/website/ly-examples if [ -d $(EXAMPLES) ]; \ then \ cp $(EXAMPLES)/* $(OUT)/website/ly-examples ; \ fi website: website-texinfo website-css website-pictures website-examples web-post in sum, if you create $HOME/lilypond/media/pictures $HOME/lilypond/media/ly-examples directories, copy the relevant files into those, and run make -f ../make/website.make WEBSITE_ONLY_BUILD=1 website then you should see exactly the same thing as you do on lilypond.org I think the next step is to do this to make sure that I haven't forgotten or glossed over any other steps, and then to make sure that this is clear on 6.2. Then you can test future changes to the website with the same mechanism that we use to create lilypond.org. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1563 in lilypond: strange vertical line at staff begin using StaffSymbol #'staff-space
Updates: Status: Verified Comment #7 on issue 1563 by philehol...@googlemail.com: strange vertical line at staff begin using StaffSymbol #'staff-space http://code.google.com/p/lilypond/issues/detail?id=1563 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Ugly collision between broken Slur and PhrasingSlur
Hi,
following the late discussions on bug- and -user, I stumbled over an
ugly collision between a phrasingSlur and a Slur at the beginning of a
second staff. Actually the phrasing slur tries to escape the slur but
does this in a spectacular way - while the collision is still there:
\version "2.15.5"
\relative a'
{
\key d \major
\time 2/2
\clef treble
a2.\(( d8[ cis] | \break
b2 cis4) b\) | \break
a2.\((\p d8[ cis] | \break
b2.) cis4\) | \break
}
The breaks are needed because in the real example there are many notes
in the piano ...
In lines 1 and 2 it is only an ugly collision (probably an instance of
issue #427?)
but lines 3 and 4 (when the slur ends on the first note after the line
break) are really crazy and mess up the page layout of my music completely.
Is this just issue #427 or should one add a new issue?
If not, what about the fact that #427 is abandonde?
I think this is quite an embarassing output.
Best
Ur
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1798 in lilypond: Full measure rests do not occupy correct horizontal space.
Status: Accepted Owner: Labels: Type-Defect Priority-Medium New issue 1798 by philehol...@googlemail.com: Full measure rests do not occupy correct horizontal space. http://code.google.com/p/lilypond/issues/detail?id=1798 Music engraving sources suggest that FMRs should occupy the same space as the note they are replacing. LilyPond contributors share this view. See http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01260.html for full details. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Full measure rest should take more horizontal space
- Original Message - From: "Xavier Scheuer" Since it seems I'm not the only one to consider that Full measure rest should take more horizontal space (as much horizontal space as a note of the same duration), could someone open a new issue for this on the tracker? http://code.google.com/p/lilypond/issues/detail?id=1798 -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Full measure rest should take more horizontal space
2011/7/31 Janek Warchoł : > > Wow, i'm CCed! Why? You are on my list as aesthetic guru (+ good engraving practices). And also because Gmail's "Consider including" feature suggested me to Cc you (and finally because it usually makes the person reply to the message, which is good in order to hear its opinions). > > […] > > I think i agree that full measure rest should take the same amount of > space as full measure note. :) On 31 July 2011 13:02, Phil Holmes wrote: > > Gould and Read both strongly imply that a WMR should take up the same space > as the equivalent note: we could discuss whether this is always a > semi-breve, or whether it represents the timed length of the note in other > time sigs than 4/4. Gould says "Position a rest exactly as if it were a > note of equivalent duration" [except] "the semi-breve rest is placed at the > visual centre of the bar". Read says "Written rests [..] are always given a > time-value: that is, the rest symbols merely substitute for a written note > value." Thank you Phil. Since it seems I'm not the only one to consider that Full measure rest should take more horizontal space (as much horizontal space as a note of the same duration), could someone open a new issue for this on the tracker? Thanks in advance. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1762 in lilypond: mutual cues fail
Updates: Status: Fixed Labels: Fixed_2_15_8 Comment #6 on issue 1762 by colinpkc...@gmail.com: mutual cues fail http://code.google.com/p/lilypond/issues/detail?id=1762 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Comment #23 on issue 1663 by philehol...@googlemail.com: Images missing on web site http://code.google.com/p/lilypond/issues/detail?id=1663 The instructions in 6.2 are _much_ more exhaustive than "run make website". If you look at current lilypond.org, everything is there - pictures, css, the lot. Therefore it surely must be that there's no problem with building the full website. Let's be clear about this. AFAICS "make website" has never made the full website - it's a quick check that you can correctly create HTML. I have a version of lilypond in my old copy of ubuntu that I have not touched since well before I made any changes that affect the website. It has no pictures, css, or anything. I've ploughed through the code of make website - there's absolutely no chance that any of this will ever be created. TBH, the battle to prove that I've done checking is getting hard - please look at comment 19 and select an option - unless you can revert to a version of lily from 2 months ago, run make; make website; and show me a website with pictures. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Comment #22 on issue 1663 by percival.music.ca: Images missing on web site http://code.google.com/p/lilypond/issues/detail?id=1663 After following the instructions in 6.2, you should have a fully-functional version of the pages on lilypond.org, with the exception of the old website in lilypond.org/web/ and any subdirectories of lilypond.org/doc/ This includes css and images. Anything less than that points to a problem in 6.2. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Comment #21 on issue 1663 by philehol...@googlemail.com: Images missing on web site http://code.google.com/p/lilypond/issues/detail?id=1663 No. I obviously don't build the lilypond.org website, but my assumption is that it has to come from /build/out-www/offline-root/Documentation/web/ which is only created as part of make doc. make website has only ever built a subset of the full website documentation - some html files; no pictures, no css, no manuals. I couldn't claim that I could write all this documentation off the top of my head, but it might make sense to create a new issue: "Improve documentation of make" and use that to explore/document the make xxx types and the options associated with them. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
