Re: Organ template in fundamental.itely is incomplete
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...
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...
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...
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...
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...
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
> 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)
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)
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...
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...
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
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
> 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
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
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)
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
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.
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...
> 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)
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