Re: articulate grace notes with time stealing (issue 7017045)

2013-01-01 Thread pkx166h

author  Zefram zef...@fysh.org  
Sat, 22 Dec 2012 21:43:42 + (21:43 +)
committer   James Lowe pkx1...@gmail.com
Tue, 1 Jan 2013 11:46:41 + (11:46 +)
commit  98edd1f29c3b5b488ea41313445a3e6220c4a245

https://codereview.appspot.com/7017045/

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


Re: canonicalise notional octave of tonic (issue 7019045)

2013-01-01 Thread pkx166h

author  Zefram zef...@fysh.org  
Mon, 24 Dec 2012 23:00:35 + (23:00 +)
committer   James Lowe pkx1...@gmail.com
Tue, 1 Jan 2013 12:02:48 + (12:02 +)
commit  60015c1d4aff30a610dced9a565fc1a6cb292be2

https://codereview.appspot.com/7019045/

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


Issue 3061 (issue 7033045)

2013-01-01 Thread pkx166h

Reviewers: zefram_fysh.org,

Description:
Issue 3061

articulate TremoloEvent

Expand TremoloEvent to repeated notes, in the unfolding stage of
articulation.

Please review this at https://codereview.appspot.com/7033045/

Affected files:
  M ly/articulate.ly


Index: ly/articulate.ly
diff --git a/ly/articulate.ly b/ly/articulate.ly
index  
6f095103a8c74037e60801e65a57e36840aea330..3b8c11020d762cabb9f8dc82158f5ddebd05d768  
100644

--- a/ly/articulate.ly
+++ b/ly/articulate.ly
@@ -92,6 +92,7 @@
 \version 2.16.0

 #(use-modules (srfi srfi-1))
+#(use-modules (srfi srfi-11))
 #(use-modules (ice-9 debug))
 #(use-modules (scm display-lily))

@@ -443,6 +444,42 @@
 (- rc (length ealtl))
 	 (lambda (i) (list (ly:music-deep-copy body) (ly:music-deep-copy (car  
ealtl)

(map (lambda (alt) (list (ly:music-deep-copy body) alt))
+ ((EventChord)
+  (let-values
+   (((trem evl)
+(partition (lambda (v) (eq? (ly:music-property v 'name) 'TremoloEvent))
+ (ly:music-property m 'elements
+   (if (null? trem)
+   m
+   (let*
+((tremtype (ly:music-property (car trem) 'tremolo-type))
+ (tremtype-log (1- (integer-length tremtype)))
+	  (durev (find (lambda (v) (not (null? (ly:music-property v 'duration  
evl))
+	  (totaldur (if durev (ly:music-property durev 'duration)  
(ly:make-duration tremtype-log 0 1)))

+ (tgt-nrep (* (/ (ash 1 tremtype-log) (ash 1 (ly:duration-log 
totaldur)))
+  (/ (1- (ash 2 (ly:duration-dot-count totaldur)))
+ (ash 1 (ly:duration-dot-count totaldur)
+ (eff-nrep (max (truncate tgt-nrep) 1))
+ (tremdur (ly:make-duration tremtype-log 0
+   (* (/ tgt-nrep eff-nrep) (ly:duration-scale totaldur)
+(or (and (= eff-nrep tgt-nrep) (= (ash 1 tremtype-log) tremtype))
+ (ly:warning (_ non-integer tremolo ~a:~a)
+  (duration-lily-string
+   (ly:make-duration
+(ly:duration-log totaldur)
+(ly:duration-dot-count totaldur)
+1)
+   #:force-duration #t
+   #:time-scale 1)
+  tremtype))
+(for-each
+ (lambda (v)
+  (or (null? (ly:music-property v 'duration))
+   (set! (ly:music-property v 'duration) tremdur)))
+ evl)
+(set! (ly:music-property m 'elements) evl)
+(make-sequential-music
+ (list-tabulate eff-nrep (lambda (i) (ly:music-deep-copy m
  ((MultiMeasureRestMusic)
   (make-sequential-music
(list
@@ -828,7 +865,7 @@ articulate = #(define-music-function (parser location  
music)

(lambda ()
 (music-map
  ac:articulate-chord
- (event-chord-wrap! (ac:unfoldMusic music) parser)))
+ (ac:unfoldMusic (event-chord-wrap! music parser
(lambda ()
 (or (= ac:stealForward 0)
  (begin



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


typo in time-signature-settings.scm (issue 7030052)

2013-01-01 Thread thomasmorley65

Reviewers: ,

Message:
Quite trivial.
Nevertheless, please review

Description:
typo in time-signature-settings.scm

Fixing missing space in commented example

issue 3074

Please review this at https://codereview.appspot.com/7030052/

Affected files:
  M scm/time-signature-settings.scm


Index: scm/time-signature-settings.scm
diff --git a/scm/time-signature-settings.scm  
b/scm/time-signature-settings.scm
index  
af852575dcedeb521c56b44be4672d29e1b21210..6beae72e6032173cd0c09555cb922522ed09c82b  
100644

--- a/scm/time-signature-settings.scm
+++ b/scm/time-signature-settings.scm
@@ -48,7 +48,7 @@
 ;;; ((1 . 8) . (3 3 2))
 ;;; will cause all primary beams to be broken at 3/8, 6/8, and 8/8.
 ;;;
-;;; ((1. 32) . (16 8 4 4))
+;;; ((1 . 32) . (16 8 4 4))
 ;;; will cause all 1/32, 1/64, and 1/128 beams to be broken at 1/2,  
3/4,

 ;;; 7/8, and 8/8.
 ;;;



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


Re: typo in time-signature-settings.scm (issue 7030052)

2013-01-01 Thread tdanielsmusic

LGTM

https://codereview.appspot.com/7030052/

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


Re: Fix for segfault in Font_metric::mark_smob (optimization; Debian bug #684817)

2013-01-01 Thread Don Armstrong
On Fri, 28 Dec 2012, David Kastrup wrote:
 Don Armstrong d...@debian.org writes:
  The attached patch fixes a segfault in mark_smob where s gets
  optimized away and garbage collected before m goes out of scope,
  leading to a segfault.
 
  There may be other cases of this bug floating around, but I didn't
  look particularly hard for them.
 
  diff --git a/lily/font-metric.cc b/lily/font-metric.cc
  index 6990afe..8ca88ef 100644
  --- a/lily/font-metric.cc
  +++ b/lily/font-metric.cc
  @@ -106,6 +106,9 @@ Font_metric::mark_smob (SCM s)
   {
 Font_metric *m = (Font_metric *) SCM_CELL_WORD_1 (s);
 m-derived_mark ();
  +  // we must do this to avoid s being optimized out and garbage
  +  // collected; leading to a segfault above.
  +  scm_remember_upto_here_1(s);
 return m-description_;
   }
 
 That makes precious little sense: mark_smob is only called while garbage
 collection is in progress, so garbage collection can't be triggered in
 its middle.

The backtrace for this bug is here: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=55;filename=lilypond-segfault.txt;att=1;bug=684817

And the attached patch does fix it; however, it's possible that this
is just because the patch obfuscates the actual bug. I'm certainly not
an expert in guile nor lilypond internals at all.


Don Armstrong

-- 
Your absence has gone through me
Like thread through a needle.
Everything I do is stitched with its color.
 -- W. S. Merwin Poetry in Motion p107

http://www.donarmstrong.com  http://rzlab.ucr.edu

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


Re: Fix for segfault in Font_metric::mark_smob (optimization; Debian bug #684817)

2013-01-01 Thread David Kastrup
Don Armstrong d...@debian.org writes:

 On Fri, 28 Dec 2012, David Kastrup wrote:
 Don Armstrong d...@debian.org writes:
  The attached patch fixes a segfault in mark_smob where s gets
  optimized away and garbage collected before m goes out of scope,
  leading to a segfault.
 
  There may be other cases of this bug floating around, but I didn't
  look particularly hard for them.
 
  diff --git a/lily/font-metric.cc b/lily/font-metric.cc
  index 6990afe..8ca88ef 100644
  --- a/lily/font-metric.cc
  +++ b/lily/font-metric.cc
  @@ -106,6 +106,9 @@ Font_metric::mark_smob (SCM s)
   {
 Font_metric *m = (Font_metric *) SCM_CELL_WORD_1 (s);
 m-derived_mark ();
  +  // we must do this to avoid s being optimized out and garbage
  +  // collected; leading to a segfault above.
  +  scm_remember_upto_here_1(s);
 return m-description_;
   }
 
 That makes precious little sense: mark_smob is only called while garbage
 collection is in progress, so garbage collection can't be triggered in
 its middle.

 The backtrace for this bug is here: 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=55;filename=lilypond-segfault.txt;att=1;bug=684817

 And the attached patch does fix it; however, it's possible that this
 is just because the patch obfuscates the actual bug. I'm certainly not
 an expert in guile nor lilypond internals at all.

More likely there is a difference in behavior because you recompiled
with different options in order to facilitate debugging or used a
different compiler.

Or the added code caused different memory layout.  At any rate, the
patch does not make sense.  The bug report also is for LilyPond 2.14.2.
A possible fix was committed as

commit 13fc2437e2aaa9ec5a65926dcb54d233a4797f45
Author: Joe Neeman joenee...@gmail.com
Date:   Fri Jul 15 09:56:28 2011 +1000

Fix a segfault caused by improper initialization of SCM.

diff --git a/lily/pango-font.cc b/lily/pango-font.cc
index a4fea75..26f2e53 100644
--- a/lily/pango-font.cc
+++ b/lily/pango-font.cc
@@ -47,6 +47,10 @@ Pango_font::Pango_font (PangoFT2FontMap *fontmap,
PangoFontDescription const *description,
Real output_scale)
 {
+  // This line looks stupid, but if we don't initialize physical_font_tab_ befo
+  // we allocate memory in scm_c_make_hash_table, then that could trigger a gar
+  // collection.
+  physical_font_tab_ = SCM_EOL;
   physical_font_tab_ = scm_c_make_hash_table (11);
   PangoDirection pango_dir = PANGO_DIRECTION_LTR;
   context_ = pango_context_new ();


in version 2.15.6.

-- 
David Kastrup


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


Re: make doc: cannot import name TexModule (but dblatex is now arequireddependency)

2013-01-01 Thread Federico Bruni

Il 30/12/2012 09:06, Federico Bruni ha scritto:

I can't find any information about dblatex developers.
I'll send a bug report to Debian bug tracking system.


Ok, problem solved thanks to the Debian maintainer:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696976

The problem was the python package merengue (installed in /usr/local 
with pip), which contains a file called plugins/TexModule.py

After running 'pip uninstall merengue' dblatex works fine again.

The following command helped to understand what was happening under the 
hood:

strace -e open dblatex example.xml

Cheers
--
Federico

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


Re: Issue 3061 (issue 7033045)

2013-01-01 Thread Zefram
d...@gnu.org wrote:
All this seems far too complex.  Why not use ly:duration-length and just
divide the respective values of ly:moment-main?  No need to fiddle with
counting dots and shift factors manually.

That's a valid approach, but doesn't win quite as much as you'd think.
In the most obvious form, it would change the tgt-nrep binding to
something like this (untested):

 (tgt-nrep (/ (ly:moment-main (ly:duration-length totaldur))
  (ly:moment-main (ly:make-duration tremtype-log 0
(ly:duration-scale totaldur)

It does involve fewer function applications (6 instead of 11).  But on
the downside it'll break if the note has been scaled by a factor of zero.
Fixing that increases the complexity:

 (tgt-nrep (/ (ly:moment-main
(ly:duration-length
  (ly:make-duration (ly:duration-log totaldur)
(ly:duration-dot-count totaldur)
1)))
  (ly:moment-main (ly:make-duration tremtype-log 0 1

Eight function applications, still fewer than my original, but it has
more long function names (and so takes more text lines given a reasonable
length limit), and doesn't avoid the need for the code to know about dot
counts.  It doesn't have to *understand* dot counts, though, so that's
a bit of a win.  Also, the de-scaled version of totaldur can be brought
out as a separate binding and then reused for the non-integer tremolo
warning message.  I'd be happy for such a variant of my patch to be used
in place of the original; I see no compelling grounds to go either way.

Generally, the complexity of the code I submitted comes from being
robust in the face of possibly uncooperative data.  I'm thinking about
situations such as where the overall duration is not an exact multiple
of the nominal tremolo duration, or the music has been subjected to time
scaling, possibly by awkward factors.

I think what would *really* make this code more readable is a bunch of
library functions covering common subexpressions that are likely to come
up in music processing.  For example:

(define (duration-dot-factor dotcount)
(/ (1- (ash 2 dotcount)) (ash 1 dotcount)))

(define (duration-descale dur)
(ly:make-duration (ly:duration-log dur) (ly:duration-dot-count dur) 1))

I've written some much larger chunks of LP Scheme code that I ought to
trawl for opportunities like this.

Also, of some relevance to this code, the system of moment objects
is a bit cumbersome.  I can see why you need the two-part structure for
aligning music columns in the output, but it looks like most things using
moment structures only use the main part, making it just an unnecessary
wrapper around rationals.  The arithmetic on them hasn't been thought out
properly: ly:moment-div returning a moment is just ridiculous.  It'd be
nice if moments were restricted to their proper role in typesetting,
and everything else just used rationals.  (With grace note articulation
through \articulate working, I think it'd be viable for basic MIDI output
to totally ignore grace notes, just as it ignores most articulations,
so even it wouldn't need moment structures.  But I digress.)

So, getting back to the subject, let me know if you'd like me to produce
a complete tremolo patch based on the variant that I described above.
Or a patch factoring out some of the code into a library of wider utility.

-zefram

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