Re: Organ template in fundamental.itely is incomplete

2010-07-12 Thread Trevor Daniels


Werner LEMBERG wrote Sunday, July 11, 2010 6:38 PM


The organ template given in `fundamental.itely' lacks an 
important

property, namely the limited stretchability of the pedal staff.
Without this, the distance of the pedal staff w.r.t. the other 
two

staves can become far too big.


Here's a documentation patch.


Hi Werner

LGTM

The patch looks fine, but as this is the only place in
Learning that mentions sub-properties and stretchability
of staves there should be index entries for these two
concepts.

Trevor



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


Re: scheme night-mare...

2010-07-12 Thread Arno Waschk


Just finished a profile run with a larger score- ly_scm2interval is  
reported to have consumd 16% of computation time. There must be  
something wrong.




... which appears in a loop, which is performed >2 billions times (!) for  
a 18 a3 page test score.

Says gprof...

Is that possible/necessary?

Yours, Arno

--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

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


Re: scheme night-mare...

2010-07-12 Thread Carl Sorensen



On 7/12/10 4:48 AM, "Arno Waschk"  wrote:

>> 
>> Just finished a profile run with a larger score- ly_scm2interval is
>> reported to have consumd 16% of computation time. There must be
>> something wrong.
>> 
> 
> ... which appears in a loop, which is performed >2 billions times (!) for
> a 18 a3 page test score.
> Says gprof...
> 
> Is that possible/necessary?

Well, if it's an 18 page score, then there are lots of page break options,
and so there would be lots of calculations.   2 billion seems like a lot,
but there are a lot of ways to figure out line and page breaks in 18 pages
of score

ly_scm2interval is part of the beam scoring code.  So that might be where
many of the calls come from.

I'm not sure what the fix might be.

Carl


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


Re: scheme night-mare...

2010-07-12 Thread Arno Waschk
On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen   
wrote:






On 7/12/10 4:48 AM, "Arno Waschk"  wrote:



Just finished a profile run with a larger score- ly_scm2interval is
reported to have consumd 16% of computation time. There must be
something wrong.



... which appears in a loop, which is performed >2 billions times (!)  
for

a 18 a3 page test score.
Says gprof...

Is that possible/necessary?


Well, if it's an 18 page score, then there are lots of page break  
options,

and so there would be lots of calculations.   2 billion seems like a lot,
but there are a lot of ways to figure out line and page breaks in 18  
pages

of score

ly_scm2interval is part of the beam scoring code.  So that might be where
many of the calls come from.




no, from the beam thing it is only called ~1000 tmes, the two billion come  
from a loop in Axis_group_interface::combine_pure_heights (...)

Yours, Arno


I'm not sure what the fix might be.

Carl




--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

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


Re: scheme night-mare...

2010-07-12 Thread Arno Waschk
On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen   
wrote:






On 7/12/10 4:48 AM, "Arno Waschk"  wrote:



Just finished a profile run with a larger score- ly_scm2interval is
reported to have consumd 16% of computation time. There must be
something wrong.



... which appears in a loop, which is performed >2 billions times (!)  
for

a 18 a3 page test score.
Says gprof...

Is that possible/necessary?


Well, if it's an 18 page score, then there are lots of page break  
options,

and so there would be lots of calculations.   2 billion seems like a lot,
but there are a lot of ways to figure out line and page breaks in 18  
pages

of score


and breaks.size() is 1202. just for info.



ly_scm2interval is part of the beam scoring code.  So that might be where
many of the calls come from.

I'm not sure what the fix might be.

Carl


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



--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

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


Re: scheme night-mare...

2010-07-12 Thread Carl Sorensen
Arno,

I think you're doing a great job of tracking this issue down!

Keep up the good work,

Carl


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


Re: Organ template in fundamental.itely is incomplete

2010-07-12 Thread Werner LEMBERG

> The patch looks fine, but as this is the only place in Learning that
> mentions sub-properties and stretchability of staves there should be
> index entries for these two concepts.

Done.


Werner


==


--- fundamental.itely   2010-05-15 16:16:53.0 +0200
+++ fundamental.itely.new   2010-07-12 18:09:10.0 +0200
@@ -2819,6 +2819,79 @@
 @}  % end Score context
 @end example
 
+...@cindex stretchability of staves
+...@cindex staves, stretchability
+
+The above layout of the organ staves is almost perfect; however,
+there is a slight defect which is not visible by looking at just a
+single system: The distance of the pedal staff to the left hand staff
+should behave approximately the same as the right hand staff to the
+left hand staff.  In particular, the stretchability of staves in a
+...@code{pianostaff} context is limited (so that the distance between
+the staves for the left and right hand can't become too large), and
+the pedal staff should behave similarly.
+
+...@cindex sub-properties
+...@cindex properties, sub-properties
+...@cindex graphical objects
+...@cindex objects, graphical
+...@cindex grobs
+
+Stretchability of staves can be controlled with the
+...@code{next-staff-spacing} property of the @code{VerticalAxisGroup}
+...@q{graphical object} (commonly called @q{grob}s within the lilypond
+documentation) -- don't worry about the details right now; this is
+fully explained later.  For the curious, have a look at
+...@ruser{overview of modifying properties}.  Currently, it is not
+possible to modify the @code{stretchability} sub-property only, we
+thus have to copy the other sub-properties also.  Again, for the
+curious, you can find the default values in file
+...@file{scm/@/define-grobs@/.scm} by looking up the definition of the
+...@code{verticalaxisgroup} grob.  The value for @code{stretchability}
+is taken from the definition of the @code{PianoStaff} context (in
+file @file{ly/@/engraver-init@/.ly}) so that the values are
+identical.
+
+...@example
+\score @{
+  <<  % PianoStaff and Pedal Staff must be simultaneous
+\new PianoStaff <<
+  \new Staff = "ManualOne" <<
+\keyTime  % set key and time signature
+\clef "treble"
+\new Voice @{
+  \voiceOne
+  \ManualOneVoiceOneMusic
+@}
+\new Voice @{
+  \voiceTwo
+  \ManualOneVoiceTwoMusic
+@}
+  >>  % end ManualOne Staff context
+  \new Staff = "ManualTwo" \with @{
+\override VerticalAxisGroup
+  #'next-staff-spacing = #'((space . 9)
+(minimum-distance . 8)
+(padding . 1)
+(stretchability . 5))
+  @} <<
+\keyTime
+\clef "bass"
+\new Voice @{
+  \ManualTwoMusic
+@}
+  >>  % end ManualTwo Staff context
+>>  % end PianoStaff context
+\new Staff = "PedalOrgan" <<
+  \keyTime
+  \clef "bass"
+  \new Voice @{
+\PedalOrganMusic
+  @}
+>>  % end PedalOrgan Staff
+  >>
+...@}  % end Score context
+...@end example
 That completes the structure.  Any three-staff organ music
 will have a similar structure, although the number of voices
 may vary.  All that remains now
@@ -2862,7 +2935,13 @@
   \ManualOneVoiceTwoMusic
 }
   >>  % end ManualOne Staff context
-  \new Staff = "ManualTwo" <<
+  \new Staff = "ManualTwo" \with {
+\override VerticalAxisGroup
+  #'next-staff-spacing = #'((space . 9)
+(minimum-distance . 8)
+(padding . 1)
+(stretchability . 5))
+  } <<
 \keyTime
 \clef "bass"
 \new Voice {

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


Re: Patch for issue #1116 (one stencil in fill-line) (issue1689041)

2010-07-12 Thread perpeduumimmobile

Reviewers: joeneeman, Neil Puttock,

Message:
On 2010/06/30 18:34:35, joeneeman wrote:

Are you still waiting for someone to review this?


Sorry, missed the notifications - I don't usually check my gmail
account.


http://codereview.appspot.com/1689041/diff/2001/3001#newcode848
scm/define-markup-commands.scm:848: X RIGHT fill-space

line-stencils)))

These two set!s could be written more concisely as [..]

As Neil noted, it's for the if.


http://codereview.appspot.com/1689041/diff/2001/3001#newcode850
scm/define-markup-commands.scm:850: (if (> word-count 1)
I know there aren't many comments in the code, but that doesn't mean

you can't

add one...

Okay. :-) Better?

Description:
Patch for issue #1116 (one stencil in fill-line)

Avoid translation of stencils if only one markup is given as argument
for fill-line.
Regressions not checked yet.

Please review this at http://codereview.appspot.com/1689041/show

Affected files:
  M scm/define-markup-commands.scm



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


Re: Patch for issue #1116 (one stencil in fill-line) (issue1689041)

2010-07-12 Thread perpeduumimmobile

On 2010/07/01 22:27:42, Neil Puttock wrote:

Hi Alexander,



LGTM.

Thanks.


It just needs some regression tests; the examples from #1116 and #382

should

suffice.


I did not write those - I'm not yet perfectly convinced that the
handling of word-space is the right thing to do (see below).


http://codereview.appspot.com/1689041/diff/2001/3001#newcode845
scm/define-markup-commands.scm:845: (set! line-stencils empty-stencil)
Hmm, line-stencils isn't appropriate from this point, since it's no

longer a

list of stencils; perhaps it would be clearer to bind to another

variable?

Not sure how to name it, then. I used the large if clause, but I'm not
sure if this is good coding style in scheme? Looks more like an early
return from imperative languages...


http://codereview.appspot.com/1689041/diff/2001/3001#newcode847
scm/define-markup-commands.scm:847: (stack-stencils-padding-list
indent

Done.


Regarding word-space:

I reintroduced word-space property to ensure that texts don't collide.
This seems not the best way, though. Consider

\markup \column {
  \fill-line { "|" "|" "|" "|" }
  \fill-line { "|" "veeery long text"
   "vry long text" "|" }
}

(Without word-space in the last version of my patch, this let's the
texts collide.)
Expected output should be this text fitted into one line, not exceeding
the
linewidth unless absolutely necessary (i.e., text-width +
(n-1)*word-space >
linewidth).
I think the best way would be to solve some minimization problem in the
springs-and-rods style:
- fix the leftmost and rightmost markup to hit the boundaries of the
line
- minimize sum over all squared distances of center of texts and optimal
  center points, which are at (2*i / (2*n+1) * line-width) for n
stencils,
  subject to non-overlapping texts.
  Perhaps, a weight should be added depending on the lengths of the
texts:
  The narrower the text, the more visible is the deviation from the
optimal
  position, IMHO.
IIUC, the necessary code for the optimization is already there, but I
don't
know where to look. I certainly could reinvent the wheel and implement
the
Simplex algorithm in Scheme, but I'm sure someone already did better.

http://codereview.appspot.com/1689041/show

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


Re: scheme night-mare...

2010-07-12 Thread Joe Neeman
On Monday, July 12, 2010 06:51:15 am Arno Waschk wrote:
> On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen 
> 
> wrote:
> > On 7/12/10 4:48 AM, "Arno Waschk"  wrote:
> >>> Just finished a profile run with a larger score- ly_scm2interval is
> >>> reported to have consumd 16% of computation time. There must be
> >>> something wrong.
> >> 
> >> ... which appears in a loop, which is performed >2 billions times (!)
> >> for
> >> a 18 a3 page test score.
> >> Says gprof...
> >> 
> >> Is that possible/necessary?
> > 
> > Well, if it's an 18 page score, then there are lots of page break
> > options,
> > and so there would be lots of calculations.   2 billion seems like a lot,
> > but there are a lot of ways to figure out line and page breaks in 18
> > pages
> > of score
> > 
> > ly_scm2interval is part of the beam scoring code.  So that might be where
> > many of the calls come from.
> 
> no, from the beam thing it is only called ~1000 tmes, the two billion come
>  from a loop in Axis_group_interface::combine_pure_heights (...)

This sounds excessive; if we cache more sensibly, this should reduce by at 
least a factor of 100. Does your score have many staves? Also, how many times 
is Align_interface::get_pure_child_y_translation called?

Cheers,
Joe

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


Re: scheme night-mare...

2010-07-12 Thread Arno Waschk

On Mon, 12 Jul 2010 22:23:04 +0200, Joe Neeman  wrote:


On Monday, July 12, 2010 06:51:15 am Arno Waschk wrote:

On Mon, 12 Jul 2010 15:02:26 +0200, Carl Sorensen 

wrote:
> On 7/12/10 4:48 AM, "Arno Waschk"  wrote:
>>> Just finished a profile run with a larger score- ly_scm2interval is
>>> reported to have consumd 16% of computation time. There must be
>>> something wrong.
>>
>> ... which appears in a loop, which is performed >2 billions times (!)
>> for
>> a 18 a3 page test score.
>> Says gprof...
>>
>> Is that possible/necessary?
>
> Well, if it's an 18 page score, then there are lots of page break
> options,
> and so there would be lots of calculations.   2 billion seems like a  
lot,

> but there are a lot of ways to figure out line and page breaks in 18
> pages
> of score
>
> ly_scm2interval is part of the beam scoring code.  So that might be  
where

> many of the calls come from.

no, from the beam thing it is only called ~1000 tmes, the two billion  
come

 from a loop in Axis_group_interface::combine_pure_heights (...)


This sounds excessive; if we cache more sensibly, this should reduce by  
at
least a factor of 100. Does your score have many staves? Also, how many  
times

is Align_interface::get_pure_child_y_translation called?

Cheers,
Joe



Hi, the mentioned routine is called ~ 23 times and does hardly consume  
time according to gprof.
it is a cello and piano score with quite lot systems squeezed onto the a3  
pages. it contains ~ 1600 bars, and breaks.size() is around 1200 IIRC


Yours, Arno

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


Re: moving english doc to a separate subdirectory

2010-07-12 Thread Graham Percival
On Sun, Jul 11, 2010 at 06:19:49PM +0200, Werner LEMBERG wrote:
> 
> What do you think about moving
> 
>   Documentation/en/contributor
> 
> for orthogonality with the other languages?

I think it will take around 10 hours.  I also think that any
problems that develop as a result of an incomplete move would be
highly undesirable at the moment.

Wait until 2.15, but even then, I really doubt that it's worth it.

Cheers,
- Graham

PS if somebody who knows more than me about the build system + gub
+ the translation scripts wants to give a different estimate, go
ahead -- but if you haven't done significant work on these things,
don't say "oh, it sounds simple; this should only be X minutes",
because you'll be full of mao.  Or rather, you might be correct
that such a simple change *should* be X minutes, but it *won't* be
a simple change.


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


LM 4.5.3 Real music example

2010-07-12 Thread Urs Liska
> I'm not top posting.

In the mentioned chapter 4.5.3 of the LM the music example (LilyPond 2.13.27)
there is an ugly problem that shouldn't be there - especially not on this page.
I'm talking about the right hand phrasingSlur spanning from the first c'' to the
last g'. Which crosses the notes of the right hand. Maybe this is only due to
the line break, but this should be corrected - which would also be a valuable
example of "Tweaking output"
Unfortunately I can't provide a concrete suggestion as it is still a little bit
over my head. (So I suggest this addition in order to get the explanation for
myself ;-)
The change should go after the third music example, to the paragraph starting
with "The first bar is now correct. " After this sentence you might include
something like "But the phrasing slur needs further attention because it clashes
with the right hand beams in bar 3. ...". This probably needs the inclusion of
one more version of the example.

Best
Urs


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


RE: LM 4.5.3 Real music example

2010-07-12 Thread James Lowe
Already in the Tracker.

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

James


-Original Message-
From: lilypond-devel-bounces+james.lowe=datacore@gnu.org on behalf of Urs 
Liska
Sent: Mon 7/12/2010 23:57
To: lilypond-devel@gnu.org
Subject: LM 4.5.3 Real music example 
 
> I'm not top posting.

In the mentioned chapter 4.5.3 of the LM the music example (LilyPond 2.13.27)
there is an ugly problem that shouldn't be there - especially not on this page.
I'm talking about the right hand phrasingSlur spanning from the first c'' to the
last g'. Which crosses the notes of the right hand. Maybe this is only due to
the line break, but this should be corrected - which would also be a valuable
example of "Tweaking output"
Unfortunately I can't provide a concrete suggestion as it is still a little bit
over my head. (So I suggest this addition in order to get the explanation for
myself ;-)
The change should go after the third music example, to the paragraph starting
with "The first bar is now correct. " After this sentence you might include
something like "But the phrasing slur needs further attention because it clashes
with the right hand beams in bar 3. ...". This probably needs the inclusion of
one more version of the example.

Best
Urs


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


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


Re: LM 4.5.3 Real music example

2010-07-12 Thread Graham Percival
On Mon, Jul 12, 2010 at 07:18:30PM -0400, James Lowe wrote:
> Already in the Tracker.
> 
> http://code.google.com/p/lilypond/issues/detail?id=1015

Perhaps I misunderstood Urs' suggestion, but I don't see what 1015
has to do with that one.

Cheers,
- Graham

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


Re: Revised autobeam settings patch (issue1682049)

2010-07-12 Thread Carl . D . Sorensen

On 2010/07/11 23:31:50, Neil Puttock wrote:

Hi Carl,



LGTM.



The web snippet granados.ly uses beatLength, so will also need

emending.


Cheers,
Neil



THanks for catching that, Neil.  I've fixed it as well (including
updating the version).

As soon as my make doc run is complete (assuming there are no errors),
I'll post another version of the patch.

http://codereview.appspot.com/1682049/show

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


RE: LM 4.5.3 Real music example

2010-07-12 Thread James Lowe
Sorry, I jumped the gun.

This is not the issue.

James


-Original Message-
From: lilypond-devel-bounces+james.lowe=datacore@gnu.org on behalf of James 
Lowe
Sent: Tue 7/13/2010 0:18
To: Urs Liska; lilypond-devel@gnu.org
Subject: RE: LM 4.5.3 Real music example 
 
Already in the Tracker.

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

James


-Original Message-
From: lilypond-devel-bounces+james.lowe=datacore@gnu.org on behalf of Urs 
Liska
Sent: Mon 7/12/2010 23:57
To: lilypond-devel@gnu.org
Subject: LM 4.5.3 Real music example 
 
> I'm not top posting.

In the mentioned chapter 4.5.3 of the LM the music example (LilyPond 2.13.27)
there is an ugly problem that shouldn't be there - especially not on this page.
I'm talking about the right hand phrasingSlur spanning from the first c'' to the
last g'. Which crosses the notes of the right hand. Maybe this is only due to
the line break, but this should be corrected - which would also be a valuable
example of "Tweaking output"
Unfortunately I can't provide a concrete suggestion as it is still a little bit
over my head. (So I suggest this addition in order to get the explanation for
myself ;-)
The change should go after the third music example, to the paragraph starting
with "The first bar is now correct. " After this sentence you might include
something like "But the phrasing slur needs further attention because it clashes
with the right hand beams in bar 3. ...". This probably needs the inclusion of
one more version of the example.

Best
Urs


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


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


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


[PATCH] for GUB - NSIS: rework uninstall logic for LilyPad.

2010-07-12 Thread Patrick McCarty
Hi,

Here is a patch for GUB that fixes an uninstallation issue for Windows
LilyPad:

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

Thanks,
Patrick
>From 8cab842cd79ca0fcb9b1d26a361c19441feea057 Mon Sep 17 00:00:00 2001
From: Patrick McCarty 
Date: Sun, 11 Jul 2010 14:01:44 -0700
Subject: [PATCH 2/2] NSIS: rework uninstall logic for LilyPad.

Before this commit, the NSIS installer created three versions of LilyPad
(lilypad.exe, lilypad-ascii.exe, and lilypad-unicode.exe), but we should
only need two of them.

If the underlying OS does not support Unicode, we only need

  lilypad.exe
  lilypad-unicode.exe

and if Unicode *is* supported, then we need

  lilypad.exe
  lilypad-ascii.exe

Then, the default LilyPad is always "lilypad.exe", and we don't have the
extra, duplicated executable.

This commit implements the above logic, and adds "lilypad-unicode.exe"
to the list of installed files if necessary.
---
 nsis/lilypond-prepost.nsh |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/nsis/lilypond-prepost.nsh b/nsis/lilypond-prepost.nsh
index 29451be..b7fa216 100644
--- a/nsis/lilypond-prepost.nsh
+++ b/nsis/lilypond-prepost.nsh
@@ -93,14 +93,22 @@ FunctionEnd
 
 
 Function postinstall_lilypad
-   StrCpy $0 "$INSTDIR\usr\bin\lilypad"
-   CopyFiles /silent "$0.exe" "$0-unicode.exe"
ClearErrors
ReadRegStr $R0 HKLM \
"SOFTWARE\Microsoft\Windows NT\CurrentVersion" CurrentVersion
IfErrors dos exit
 dos:
-   CopyFiles /silent "$0-ascii.exe" "$0.exe"
+   # In this case, the underlying OS does not support Unicode,
+   # so the ASCII LilyPad should be the default.
+   StrCpy $0 "$INSTDIR\usr\bin\lilypad"
+   Rename "$0.exe" "$0-unicode.exe"
+   Rename "$0-ascii.exe" "$0.exe"
+   # Add lilypad-unicode.exe to files.txt to ensure complete uninstall.
+   SetFileAttributes "$INSTDIR\${UninstLog}" NORMAL
+   FileOpen $UninstLog "$INSTDIR\${UninstLog}" a
+   FileSeek $UninstLog 0 END
+   FileWrite $UninstLog "\usr\bin\lilypad-unicode.exe$\r$\n"
+   FileClose $UninstLog
 exit:  
 FunctionEnd
 
-- 
1.7.1.1

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


Re: scheme night-mare...

2010-07-12 Thread Joe Neeman
> Hi, the mentioned routine is called ~ 23 times and does hardly consume
> time according to gprof.
> it is a cello and piano score with quite lot systems squeezed onto the a3
> pages. it contains ~ 1600 bars, and breaks.size() is around 1200 IIRC

Does the attached patch help? For me, it reduces dramatically the
number of times that combine_pure_heights (and also ly_scm2interval)
is called, but it has very little effect on lilypond's overall running
time (for the optimized build, at least).

Cheers,
Joe
From bd562d3d3e83a2545209bad8f6e97e2e263e8fe4 Mon Sep 17 00:00:00 2001
From: Joe Neeman 
Date: Mon, 12 Jul 2010 18:07:06 -0700
Subject: [PATCH] Optimizations.

---
 lily/axis-group-interface.cc |   49 +-
 lily/include/axis-group-interface.hh |3 +-
 lily/note-head.cc|   21 +-
 stepmake/aclocal.m4  |2 +-
 4 files changed, 52 insertions(+), 23 deletions(-)

diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc
index 18994f1..42ed69f 100644
--- a/lily/axis-group-interface.cc
+++ b/lily/axis-group-interface.cc
@@ -87,7 +87,7 @@ Axis_group_interface::relative_group_extent (vector const &elts,
 }
 
 Interval
-Axis_group_interface::cached_pure_height (Grob *me, int start, int end)
+Axis_group_interface::sum_partial_pure_heights (Grob *me, int start, int end)
 {
   Interval iv = begin_of_line_pure_height (me, start);
   iv.unite (rest_of_line_pure_height (me, start, end));
@@ -96,27 +96,50 @@ Axis_group_interface::cached_pure_height (Grob *me, int start, int end)
 }
 
 Interval
-Axis_group_interface::rest_of_line_pure_height (Grob *me, int start, int end)
+Axis_group_interface::part_of_line_pure_height (Grob *me, bool begin, int start, int end)
 {
+  SCM cache_sym = begin ? ly_symbol2scm ("start-pure-height-cache")
+: ly_symbol2scm ("rest-pure-height-cache");
+  SCM key = begin ? scm_from_int (start) : scm_cons (scm_from_int (start), scm_from_int (end));
+  SCM pure_height_cache = me->get_property (cache_sym);
+
+  if (to_boolean (scm_hash_table_p (pure_height_cache)))
+{
+  SCM cached = scm_hash_ref (pure_height_cache, key, SCM_BOOL_F);
+  if (scm_is_pair (cached))
+	return robust_scm2interval (cached, Interval (0, 0));
+}
+
   SCM adjacent_pure_heights = me->get_property ("adjacent-pure-heights");
+  if (!scm_is_pair (adjacent_pure_heights))
+return Interval (0, 0);
+  SCM these_pure_heights = begin ? scm_car (adjacent_pure_heights) :
+scm_cdr (adjacent_pure_heights);
 
-  if (!scm_is_pair (adjacent_pure_heights)
-  || !scm_is_vector (scm_cdr (adjacent_pure_heights)))
+  if (!scm_is_vector (these_pure_heights))
 return Interval (0, 0);
 
-  return combine_pure_heights (me, scm_cdr (adjacent_pure_heights), start, end);
+  Interval ret = combine_pure_heights (me, these_pure_heights, start, end);
+  if (!to_boolean (scm_hash_table_p (pure_height_cache)))
+{
+  pure_height_cache = scm_c_make_hash_table (1000);
+  me->set_property (cache_sym, pure_height_cache);
+}
+  scm_hash_set_x (pure_height_cache, key, ly_interval2scm (ret));
+
+  return ret;
 }
 
 Interval
-Axis_group_interface::begin_of_line_pure_height (Grob *me, int start)
+Axis_group_interface::rest_of_line_pure_height (Grob *me, int start, int end)
 {
-  SCM adjacent_pure_heights = me->get_property ("adjacent-pure-heights");
-
-  if (!scm_is_pair (adjacent_pure_heights)
-  || !scm_is_vector (scm_car (adjacent_pure_heights)))
-return Interval (0, 0);
+  return part_of_line_pure_height (me, false, start, end);
+}
 
-  return combine_pure_heights (me, scm_car (adjacent_pure_heights), start, start+1);
+Interval
+Axis_group_interface::begin_of_line_pure_height (Grob *me, int start)
+{
+  return part_of_line_pure_height (me, true, start, start+1);
 }
 
 Interval
@@ -237,7 +260,7 @@ Axis_group_interface::relative_pure_height (Grob *me, int start, int end)
  we can assume additivity and cache things nicely. */
   Grob *p = me->get_parent (Y_AXIS);
   if (p && Align_interface::has_interface (p))
-return Axis_group_interface::cached_pure_height (me, start, end);
+return Axis_group_interface::sum_partial_pure_heights (me, start, end);
 
   Grob *common = unsmob_grob (me->get_object ("pure-Y-common"));
   extract_grob_set (me, "pure-relevant-items", items);
diff --git a/lily/include/axis-group-interface.hh b/lily/include/axis-group-interface.hh
index bd038c7..ac765d2 100644
--- a/lily/include/axis-group-interface.hh
+++ b/lily/include/axis-group-interface.hh
@@ -48,9 +48,10 @@ struct Axis_group_interface
 	 Grob *common, Axis);
   static Interval relative_pure_height (Grob *me, int start, int end);
   static Interval combine_pure_heights (Grob *me, SCM, int, int);
-  static Interval cached_pure_height (Grob *me, int, int);
+  static Interval sum_partial_pure_heights (Grob *me, int, int);
   static Interval begin_of_line_pure_height (Grob *me, int);
   static Interval rest_of_li

Imposing Swing Upon notes (Specification)

2010-07-12 Thread Dean Radcliffe
I added the following to
http://code.google.com/p/lilypond/issues/detail?id=687

I think this is a way to think about - could anyone suggest to a novice
schemer how this might be done ??


There is a quantity called "Global Groove Amount", and a setting that
controls whether it applies to syncopated eigths or syncopated sixteenths.
It is a number, from 0 to 100 (but most useful at and around 33), which -
for the eighth note example - is ignored on quarter note beats, but for
those syncopated eigth notes, displaces them later in time by the proportion
of 100 specified. Example: assuming 100 divisions per quarter note, the
syncopated eigth-note falls on 50 without swing, but with 33 groove factor,
the number 50 is increased 33%, and so becomes 66. Notes that are neither
exact eigth notes (which have full groove factor applied), or exact quarter
notes (which are unaffected by groove factor in eigth-note mode, much like
eigth-notes are unaffected in 'swing 16th' mode) can either be left
unaffected, or proportionally affected, dependent on a configuration
override (the default should be to leave them unaffected).

This would not require lookahead, or collision avoidance, just the ability
to determine whether a given musical event is a downbeat per that
swing-mode, and the ability to alter the displacement of the note by the
product of the groove factor and a number that indicates how off-the-beat
the note is already. The visual representation of the note should not be
altered, nor other elements moved around, this only need take effect on all
audible events in midi output. This feature is basically the rhythmic
equivalent of transposition- music written one way, and played another.. but
instead of translating in the pitch domain, we are scaling in the time
domain, modulo the distance from certain interval boundaries. I would
actually suggest calling this a Swing_Performer, available only for midi
layouts (I'm not sure i have my terminology right here, but that's the idea,
in the same way you can add and remove Dynamics_Performer for midi output)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel