Re: Gets vertical skylines from grob stencils (issue 5626052)
From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I second this. I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. I still think that the `bounding outline' should be defined in the Metafont code for Emmentaler glyphs. However, this should be rather easy to add later on in case we try this route. Caching glyph outlines certainly helps, BTW. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
2012/3/1 Janek Warchoł janek.lilyp...@gmail.com: From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? You could look into some heuristic that limits the number of boxes depending on their shapes, so it creates a single box for most glyphs. For example, you could take the box enclosing the glyph and compare its area with that of the union of the boxes, and revert to one box if the difference is less than X percent. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
Han-Wen Nienhuys hanw...@gmail.com writes: 2012/3/1 Janek Warchoł janek.lilyp...@gmail.com: From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? Well, it is again an issue of incest tabu where the details of the combining skylines make best sense for combining _heterogenous_ elements: for arranging text with text, you don't want to have things get too closely or even interleaved. But having a single high letter interlock with a note stem can improve the overall arrangement. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Mar 1, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote: From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? Well, it is again an issue of incest tabu where the details of the combining skylines make best sense for combining _heterogenous_ elements: for arranging text with text, you don't want to have things get too closely or even interleaved. But having a single high letter interlock with a note stem can improve the overall arrangement. Exactly my point: you can fix the single letter case with a single bbox per glyph. Why do you need more accuracy than single box per glyph? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mar 1, 2012, at 11:52 AM, Han-Wen Nienhuys wrote: 2012/3/1 Janek Warchoł janek.lilyp...@gmail.com: From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? Janek had sent out a couple e-mails before (I can't find them). It makes a significant difference for DynamicText, and I know he has a few examples of lyrics as well where it makes a difference. David's also right about the single high letter and note stem (this was one of Janek's examples). You could look into some heuristic that limits the number of boxes depending on their shapes, so it creates a single box for most glyphs. I agree - there's a lot of room for heuristicking. For example, you could take the box enclosing the glyph and compare its area with that of the union of the boxes, and revert to one box if the difference is less than X percent. Remembering that 81.2% of all statistics are fabricated on the spot, I'd say that 70% of speed-up work could be done in skyline.cc. I think stencil-integral.cc is as fast as its gonna get. It may help to cache a FT_Face in the Pango_font class as I'm not sure how long it takes to look it up. I'm not convinced after testing that caching font outlines significantly speeds things up - there used to be some code for this, but I've removed it. It can be put back in later if it turns out that after profiling the calls to the functions in freetype.cc sap a lot of time. What I really need help on is profiling. People have so far offered great suggestions on how to do it, but I'm not too good at reading the summaries from profilers to know exactly where the resources are being consumed. If someone sent me a really detailed chart with what resources were consumed on what, that'd help immensely. The only thing that was clear to me was that LilyPond is spending a lot of time in skyline-related functions, but I'm not sure which ones. The skyline class in general looks like it needs a look-over from someone who knows something about CS and optimization. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
Han-Wen Nienhuys hanw...@gmail.com writes: On Thu, Mar 1, 2012 at 7:57 AM, David Kastrup d...@gnu.org wrote: From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? Well, it is again an issue of incest tabu where the details of the combining skylines make best sense for combining _heterogenous_ elements: for arranging text with text, you don't want to have things get too closely or even interleaved. But having a single high letter interlock with a note stem can improve the overall arrangement. Exactly my point: you can fix the single letter case with a single bbox per glyph. Why do you need more accuracy than single box per glyph? Because a q does not have its descender stick out in the middle over the full breadth. For collision avoidance, it is good for at least two boxes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
Janek Warchoł wrote Thursday, March 01, 2012 12:01 AM The bad news is that for scores containing a lot of lyrics (like my SATB pieces) compilation times are now 3-4 times longer than wiith master. For instrumental scores the situation look better, it's 1.5-2 times longer. I can live with these compilation times, but others probably won't like it... I wouldn't like it for one. Could either the precise skylines for glyphs be optionally activated, or applied only to dynamic text, not lyrics? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Mar 1, 2012 at 8:01 AM, David Kastrup d...@gnu.org wrote: Han-Wen Nienhuys hanw...@gmail.com writes: 2012/3/1 Janek Warchoł janek.lilyp...@gmail.com: From what i see, the skylines are now more precise than they need to be - every glyph has a skyline of 10 or so boxes, even if it's a single letter! (see attached) I think the proper solution would be to: a) set minimal step size to 0.2 staffspace (or more in case of bigger objects) b) change outlines from stairs to glued lines (what Joe suggested). This would allow for even less fragments for each skyline. It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? You could look into some heuristic that limits the number of boxes depending on their shapes, so it creates a single box for most glyphs. For example, you could take the box enclosing the glyph and compare its area with that of the union of the boxes, and revert to one box if the difference is less than X percent. Percentage of area differences sounds like a recipe for disaster. Once one box gets large enough, it will eat every small box in its vicinity because any single one will not make a large percentual difference. Well, perhaps there is another method. I just want to point out that it is a waste to represent the extent of the letter 'n' with 10 boxes, and we should be able to do better. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mar 1, 2012, at 12:17 PM, Trevor Daniels wrote: Janek Warchoł wrote Thursday, March 01, 2012 12:01 AM The bad news is that for scores containing a lot of lyrics (like my SATB pieces) compilation times are now 3-4 times longer than wiith master. For instrumental scores the situation look better, it's 1.5-2 times longer. I can live with these compilation times, but others probably won't like it... I wouldn't like it for one. Could either the precise skylines for glyphs be optionally activated, or applied only to dynamic text, not lyrics? The good news is that a simple property activation causes this to kick in, so before pushing the patch, we can decide what does and doesn't get this feature as default behavior. Furthermore, we can create a file precision-spacing.ly that sets tons of grobs to the more time-costly alternative for those who want to put their finished score in a final pass through the vertical-skyline functions. Now, though, it's important to develop the with everything at maximum complexity to see what type of toll it takes and get as many bugs out as possible. I still think there's a lot of room for speed up - as I said in my previous e-mail, I just need help with some profiling. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mar 1, 2012, at 12:23 PM, Han-Wen Nienhuys wrote: Well, perhaps there is another method. I just want to point out that it is a waste to represent the extent of the letter 'n' with 10 boxes, and we should be able to do better. I agree that it's excessive. To me, do better means maximally optimizing the code and then making decisions about what should get fine-tuned skylines at the end of the patch development process. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Important: GSoC mentors
On 28 February 2012 22:50, Janek Warchoł janek.lilyp...@gmail.com wrote: Mentors may or may not receive money, but they will surely win Eternal Glory (and maybe a Graham's Kiss, who knows?). Please declare which project(s) you are willing to mentor (remember that not all projects will be launched): I can't offer to mentor because my economic situation makes it rather likely that I will have ceased all LilyPond activities by summer. Damn. I see that a Kickstarter project is really urgent. Aargh, how to do all this stuff! Oh, that's simple - just find more people that will get involved ;) Łukasz ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile1 doesn't work
Werner LEMBERG wl at gnu.org writes: configure:9636: checking for guile configure:9666: result: no configure:9636: checking for guile1 configure:9652: found /usr/bin/guile1 configure:9663: result: guile1 configure:9704: checking for guile configure:9737: result: no ... The last two lines apparently overwrite the GUILE variable again. Werner This should do it: diff --git a/stepmake/aclocal.m4 b/stepmake/aclocal.m4 index c8e62a9..f7f4579 100644 --- a/stepmake/aclocal.m4 +++ b/stepmake/aclocal.m4 @@ -928,7 +928,7 @@ AC_DEFUN(STEPMAKE_PATH_PROG, [ AC_CHECK_PROGS($1, $2, no) STEPMAKE_OPTIONAL_REQUIRED($1, $2, $3) if test $? -eq 0; then - AC_PATH_PROG($1, $2) + AC_PATH_PROGS($1, $2) if test -n $4; then STEPMAKE_CHECK_VERSION($1, $3, $4) fi ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for several musicxml2ly bugs. (issue 5697059)
On 2012/02/29 22:33:45, Julien Rioux wrote:
This patch is not associated with any issue in the bug tracker. It
will not get
a proper review until it is added there, and the automatic testing
shows that it
does not cause any unexpected problems. Should it be added to issue
1983, or is
it sufficiently different that we should open a new issue for it?
Well it would certainly be easier for me if we opened a new issue for
this patch as it contains fixes for several bugs I reported lately. For
some of them no issues were opened. Here are the bugs / reports at
stake:
-) http://code.google.com/p/lilypond/issues/detail?id=1983
-)
http://old.nabble.com/musicxml2ly%3A-chordnames-placement-bug-td33309393.html
-) http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg00519.html
I also added 2 lines to Usage as the new command line options -m and
--midi hadn't been added yet.
Beyond that I have a partial fix for
(http://code.google.com/p/lilypond/issues/detail?id=1969). Should I make
a new patch or can I add the code here?
There are a lot of formatting changes to musicxml.py that are
unnecessary and
make it difficult to see the meaningful changes in your patch. You
also
introduce whitespace errors. So please revert the changes to
musicxml.py except
for...
http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py
File scripts/musicxml2ly.py (right):
http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode25
scripts/musicxml2ly.py:25: # Store command-line options in a global
variable, so
we can access them everywhere
...this typo...
OK. Will do. But I'll leave out the former lines 477 and 478 as this
_is_ a meaningful change.
Thanks for your help!
patrick
BTW: I should mention that the bugs in this patch were fixed by René
Fauck.
http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode534
scripts/musicxml2ly.py:534: return None
...and this thinko.
http://codereview.appspot.com/5697059/diff/1/scripts/musicxml2ly.py#newcode2570
scripts/musicxml2ly.py:2570: p.version = ('''%prog (LilyPond)
2.15.24\n\n'''
Especially, don't change this.
http://codereview.appspot.com/5697059/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile1 doesn't work
This should do it: - AC_PATH_PROG($1, $2) + AC_PATH_PROGS($1, $2) Yep, thanks. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for several musicxml2ly bugs. (issue 5697059)
On 12-03-01 10:23 AM, ptrcklsch...@googlemail.com wrote: Well it would certainly be easier for me if we opened a new issue for this patch as it contains fixes for several bugs I reported lately. For some of them no issues were opened. Here are the bugs / reports at stake: -) http://code.google.com/p/lilypond/issues/detail?id=1983 This sounds very straightforward; can you cook up a small patch restricted to this item alone -) http://old.nabble.com/musicxml2ly%3A-chordnames-placement-bug-td33309393.html This one sounds like issue 1969, and could probably be added as a comment. -) http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg00519.html I also added 2 lines to Usage as the new command line options -m and --midi hadn't been added yet. Because this one brings in the MIDI set of . . . complications . . . it should probably have a separate tracker item. Beyond that I have a partial fix for (http://code.google.com/p/lilypond/issues/detail?id=1969). Should I make a new patch or can I add the code here? This would involve creating a Rietveld item referencing tracker 1969, which would be the better way of handling the work in process patch. I gather you would like to create a single tracker item and merge all the above into it, but that might make the result rather too broad for easy review and analysis. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Mar 1, 2012 at 12:00 PM, m...@apollinemike.com m...@apollinemike.com wrote: On Mar 1, 2012, at 11:52 AM, Han-Wen Nienhuys wrote: It's neat that you are generating such precise skylines, but can you show places where this makes an appreciable difference for texts? Janek had sent out a couple e-mails before (I can't find them). It makes a significant difference for DynamicText, and I know he has a few examples of lyrics as well where it makes a difference. David's also right about the single high letter and note stem (this was one of Janek's examples). I attach sources of my test files. I will send pdfs compiled with both master and Mike's patch, with some of the differences highlighted, privately (4 snippets and 2 real-life scores, 4 MB). I hope you'll like it :) thanks, Janek skylines-tests-sources.tar.gz Description: GNU Zip compressed data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: old source tarballs
On Mon, Feb 27, 2012 at 1:31 PM, Graham Percival gra...@percival-music.ca wrote: We need to make more space on lilypond.org. I've deleted binaries, documentation, and regtests from everything other than the first and last release of a stable series. On the minus side, it makes it a PITA to quickly check for not-so-recent regressions (not to mention that one cannot always compile old versions, as Rune demonstrated back in '07). Can we set up an alternate FTP repository for old binaries and for archiving purposes? (I can provide it if needed, I've already set up a user-friendly file-manager interface on lilynet, including a bitTorrent tracker for binary downloads. And I've got *plenty* of space, on various servers.) Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: old source tarballs
On Thu, Mar 01, 2012 at 11:19:58PM +0100, Valentin Villenave wrote: On Mon, Feb 27, 2012 at 1:31 PM, Graham Percival gra...@percival-music.ca wrote: We need to make more space on lilypond.org. I've deleted binaries, documentation, and regtests from everything other than the first and last release of a stable series. On the minus side, it makes it a PITA to quickly check for not-so-recent regressions (not to mention that one cannot always compile old versions, as Rune demonstrated back in '07). Can we set up an alternate FTP repository for old binaries and for archiving purposes? Umm, no? I mean, literally no? Other than the first+last releases of each stable branch, those files are gone. If you can find some old binaries on some old mirror, go for it... but the old middle-of-release binaries that used to be on lilypond.org are gone now. I'm not planning on removing the .0 and .last stable release binaries, so don't worry about those. Then again, there's no harm in grabbing a copy now just in case. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
Reviewers: ,
Message:
I've seen it many times that Lilypond would crash during my experiments
with Scheme code. This time I decided to track it down. It's my first
ever fix to the C++ code in Lilypond, so please check my coding style.
Description:
Fix crash when unknown grob name is passed to ly:engraver-make-grob
Please review this at http://codereview.appspot.com/5715053/
Affected files:
M lily/engraver-scheme.cc
M lily/engraver.cc
Index: lily/engraver-scheme.cc
diff --git a/lily/engraver-scheme.cc b/lily/engraver-scheme.cc
index
8789171d7eafdd640c573c5b19cbd46ee3685102..bfc40f613cab8928f383f9a383c9e0b76d87fb51
100644
--- a/lily/engraver-scheme.cc
+++ b/lily/engraver-scheme.cc
@@ -35,7 +35,13 @@ LY_DEFINE
(ly_engraver_make_grob, ly:engraver-make-grob,
internal_make_grob (grob_name, cause,
ly_symbol2string (grob_name).c_str (),
scheme, 0, scheme);
- return g-self_scm ();
+ if (g)
+return g-self_scm ();
+ else
+{
+ programming_error (cannot create grob);
+ return SCM_EOL;
+}
}
LY_DEFINE (ly_engraver_announce_end_grob, ly:engraver-announce-end-grob,
Index: lily/engraver.cc
diff --git a/lily/engraver.cc b/lily/engraver.cc
index
b8bf1234c04d625fe36c635c38aa3bad1a24c85b..e0da6d96e8dc042c9c38f0c0a37eff8a81abd75c
100644
--- a/lily/engraver.cc
+++ b/lily/engraver.cc
@@ -118,6 +118,8 @@ Engraver::internal_make_grob (SCM symbol,
#endif
SCM props = updated_grob_properties (context (), symbol);
+ if (props == SCM_EOL)
+return 0;
Grob *grob = 0;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: old source tarballs
On Thu, Mar 1, 2012 at 11:26 PM, Graham Percival gra...@percival-music.ca wrote: Umm, no? I mean, literally no? Other than the first+last releases of each stable branch, those files are gone. Then I'm sorry to hear that. In case my honest opinion matters (hint: it doesn't), I think you screwed up big time on this. It wouldn't have taken much to do a local backup (hell, I could have launched a wget on my server and we'd have a whole clone by now). It obviously may not matter to you, but I still remember when Rune needed to track something that had occured in 2.6 or earlier. I know in an ideal world, we'd all be able to build any version at any given time, but having old development binaries *can* be useful every now and then. (It also allows regular users to bisect on their own and narrow down a regression's appearance, which can save the devs quite some time.) And before you ask, no I'm not saying I could do a better job than you in your other tasks within the LilyPond project :-) If you can find some old binaries on some old mirror, go for it... but the old middle-of-release binaries that used to be on lilypond.org are gone now. (sigh) OK. Then I guess we'll have to make do with whatever's left. (Or install old libraries/compilers in VMs if we have to try and compile oldish intermediate versions.) I'm not planning on removing the .0 and .last stable release binaries, so don't worry about those. Then again, there's no harm in grabbing a copy now just in case. I'm wgetting them now (it's messed up but i'll clean it up later). (Stable or not, I guess 2.6 and 2.4 binaries are gone too.) In any case, I'll try and keep a mirror up-to-date on files.lilynet.net. Cheers, Valentin. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: old source tarballs
Valentin Villenave wrote Thursday, March 01, 2012 11:05 PM On Thu, Mar 1, 2012 at 11:26 PM, Graham Percival gra...@percival-music.ca wrote: Umm, no? I mean, literally no? Other than the first+last releases of each stable branch, those files are gone. Then I'm sorry to hear that. In case my honest opinion matters (hint: it doesn't), I think you screwed up big time on this. It wouldn't have taken much to do a local backup (hell, I could have launched a wget on my server and we'd have a whole clone by now). I agree. Many times I've used old binaries to track down faults to a small range of commits. Can't do it now, although I do have quite a few mingw binaries for 11, 13 and 15 stashed away. Valentin - could they not be retrieved from backup if you ask nicely? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
On 2012/03/01 23:02:57, Pavel Roskin wrote: I've seen it many times that Lilypond would crash during my experiments with Scheme code. This time I decided to track it down. It's my first ever fix to the C++ code in Lilypond, so please check my coding style. How is that a fix? You return a non-grob value that will wreak havoc later on. The only thing that would seem to make some sense here is throwing a (Scheme) exception. It will likely cause an abort of the program, but in a better controlled manner that can be caught and debugged from Scheme. http://codereview.appspot.com/5715053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
As for compilation times with patchset 32, SATB choral files compile two times longer than master, and instrumentals 1.0-1.5 times longer than master. Mike, i am very sorry but i have to pause my involvement in this issue a bit. I'm very short on time and testing takes a lot of time :/ cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
important: GSoC problem, GNU isn't ready yet
Hi all, i've got a message from GNU: they don't yet have a person who will be their GSoC administrator. They welcome volunteers to do this task - any takers? If GNU won't participate in GSoC, we'll have to make an application on our own. It's certainly possible to do so and i began investigating what will be needed for this, but i welcome any help! I'm very short on time now. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mar 2, 2012, at 6:28 AM, Janek Warchoł wrote: As for compilation times with patchset 32, SATB choral files compile two times longer than master, and instrumentals 1.0-1.5 times longer than master. Mike, i am very sorry but i have to pause my involvement in this issue a bit. I'm very short on time and testing takes a lot of time :/ cheers, Janek Not a prob, Janek, and thank you _very_ much for your help. You've put as much time as I have into this thing, and I couldn't have gotten it to where it is w/o your feedback. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
