verbosity of `make doc'
Folks, I really appreciate that `make doc' doesn't flood the console. However, right now I see a long line calling lilypond-book.py which sits there for already more than 15 minutes without any progress indicator at all. This is perhaps too extreme and suitable only to the supercomputers some of us apparently have at home :-) Wouldn't it be possible, similar to automake, that the name of the currently processed file gets written to stdout, and that this behaviour is the default? In case the names are meaningless, a simple 1/1023 2/1023 3/1023 ... would also suffice as a progress indicator. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: templates and a little bit more
Am 06.04.2012 um 13:17 schrieb Janek Warchoł: > On Thu, Apr 5, 2012 at 7:37 PM, Jan-Peter Voigt wrote: >> Dear community, >> >> I bundled some extensions in a little package to try out. Some of these >> ideas might be interesting to include in lily. >> Here is a start of some docs, but just a little bit. I am working on it ... >> http://www.xn--schne-noten-tfb.de/?tabs=3,1 > > I'm sorry that i don't have time to dig deeper, Thats OK - I hope that you will be successful with your GSoC project! And that your exams don't suffer too much ;-) > but my first > impression is that it's somewhat similar to OrchestralLily: > http://lac.linuxaudio.org/2010/papers/25.pdf > http://reinhold.kainhofer.com/orchestrallily/A-simple-example.html#A-simple-example > - it may give you some inspiration. Yes I know orchestralily. > > Generally speaking, i'd very much linke to simplify writing LilyPond > scores. Have you read my article "LilyPond's future"? > (http://news.lilynet.net/?The-LilyPond-Report-25&lang=en#lilypond_s_future) > What do you think about it? I read it and I like it. It is a reason to send my stuff to the list, because I think, my ideas might be helpful in this matter. I will explain it a little bit more the next days. Cheers, Jan-Peter ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
Am 6. April 2012 23:04 schrieb Carl Sorensen : > On 4/5/12 12:51 PM, "Marc Hohl" wrote: > >> >> >>Does it make sense to replace the definitions in bar-line.cc/span-bar.cc >>with the scheme equivalents? If yes, I'd draw a patch and would include >>one example for integrating user-defined bar lines with the new approach >>as a snippet (once I get the dashed bar line right in place ...) > > It seems to me that it makes sense to put the stencil building functions > in Guile instead of in c++. No sense adding the extra interface layer for > scheme calls from c++. > > I would suggest that you make custom-bar-print-alist and > custom-bar-glyph-alist context properties, so they will be documented and > available for modification. > > Whenever I see Scheme code that says something like > > (do (( > ... > (set! foo bar))) > > I cringe a bit. This looks like a direct statement-by-statement > translation from c++, rather than an implementation in native Scheme > idioms. set! creates a side effect for the procedure, and the Scheme > gurus like to avoid side effects as much as possible (at least they did 25 > years ago ... am I really that old?). I haven't looked carefully at your > code to write an alternative, but it's likely that this code can be > rewritten either as a recursive function or as a map, fold, or apply > function, all of which are more native Scheme idioms. > > Anyway, overall this looks like great work, and I think we ought to get it > into the code base. > > Thanks, > > Carl I'm working on a very similiar stuff. But I didn' try to rewrite lily/bar-line.cc etc. I tried another approach, defining only drawing-functions for glyphs of string-length = 1 Putting them together with a recursive function. Please note: This is work in progress. You may recognize many fragments of your and Nicolas' work. Thanks to you both. Currently there are a lot of inconsequences and small issues. And I didn't work on the line-break and the span-bar so far. That's on my todo-list. :) Nevertheless, I'm able to print very curious custom-barlines. Perhaps you may get some ideas for your own work. -Harm custom-bars-01.ly Description: Binary data <>___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Work on Issue 1320
On 4/5/12 12:51 PM, "Marc Hohl" wrote: > > >Does it make sense to replace the definitions in bar-line.cc/span-bar.cc >with the scheme equivalents? If yes, I'd draw a patch and would include >one example for integrating user-defined bar lines with the new approach >as a snippet (once I get the dashed bar line right in place ...) It seems to me that it makes sense to put the stencil building functions in Guile instead of in c++. No sense adding the extra interface layer for scheme calls from c++. I would suggest that you make custom-bar-print-alist and custom-bar-glyph-alist context properties, so they will be documented and available for modification. Whenever I see Scheme code that says something like (do (( ... (set! foo bar))) I cringe a bit. This looks like a direct statement-by-statement translation from c++, rather than an implementation in native Scheme idioms. set! creates a side effect for the procedure, and the Scheme gurus like to avoid side effects as much as possible (at least they did 25 years ago ... am I really that old?). I haven't looked carefully at your code to write an alternative, but it's likely that this code can be rewritten either as a recursive function or as a map, fold, or apply function, all of which are more native Scheme idioms. Anyway, overall this looks like great work, and I think we ought to get it into the code base. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC rendering improvements
On Fri, Apr 6, 2012 at 9:10 PM, Corey F wrote: > On 2012-04-05 04:16, Janek Warchoł wrote: >>> >>> Thank you both for your help and insights -- I'll hope to put together an >>> application (while still keeping up with school etc. this week...) >> >> Yup, there is little time left - only 30 hours. > > Well, thanks for your help, but I didn't manage to write a complete proposal > that I was satisfied with quite in time for the application deadline. pity :( But i'm pretty sure there will be another GSoC in 2013 :) > Best of luck with your proposal and project, Janek! Thanks! > Depending on how my summer > plans turn out, I may well stick around and help out a bit here anyway. That would be extremely cool! I recommend starting with something not-so-big, however (yes, perhaps everyone recommends this). What kind of issues are you interested in? Maybe i could give you some suggestions for issues that are small but not boring. If you'd like to learn more about our community, you may want to read the LilyPond Report, our "newsletter": http://news.lilynet.net/?The-LilyPond-Report-25&lang=en (and perhaps some previous issues, too, as this one was quite dominated by one person). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC rendering improvements
On 2012-04-05 04:16, Janek Warchoł wrote: Thank you both for your help and insights -- I'll hope to put together an application (while still keeping up with school etc. this week...) Yup, there is little time left - only 30 hours. Well, thanks for your help, but I didn't manage to write a complete proposal that I was satisfied with quite in time for the application deadline. Best of luck with your proposal and project, Janek! Depending on how my summer plans turn out, I may well stick around and help out a bit here anyway. Corey ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: no critical issues!
On Fri, Apr 06, 2012 at 06:04:39PM +0200, m...@apollinemike.com wrote: > Release candidate anyone? Or have we already had a version bump? I can > build it, Graham, if you're over hours. It's already building. I've been trying to build it for the past few days, but I can only do it after booting my desktop into a non-ideal OS, so I need to remember to build it right before I leave university. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
no critical issues!
Release candidate anyone? Or have we already had a version bump? I can build it, Graham, if you're over hours. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120408
For 20:00 MDT Sunday April 8 Nuttin' Nada Niente No patches for review, so a restful weekend to you all! Colin Senex -- 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: second GSoC application: font glyph variants. Please review!
On 4/6/12 5:33 AM, "Janek Warchoł" wrote: > >I know nothing about any Canadian ancestors of mine, but you never >know... :) >How did you like my article about LilyPond's weak sides and it's >future development? Do you think that my concerns are valid? I think your concerns about improving the automatic decision making are exactly right. The goal needs to continue to be to get music perfect without tweaking. I'm much less concerned about simplifying the general input syntax. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: second GSoC application: font glyph variants. Please review!
On Fri, Apr 6, 2012 at 12:54 AM, Carl Sorensen wrote: > I think your proposal ought to have three steps for each set of modified > glyphs: > > 1) Add glyph variants > 2) Add infrastructure > 3) Tweak glyph variants > > I suggest this, because I think that the tweaking may take a lot of time. > If you had variants and the infrastructure complete by the end of GSOC, > but the variants weren't yet perfect, I'd consider that a successful > outcome. I think that tweaking is potentially the most time-consuming > part of the project, and the part I'd be happiest to have left to do at > the end of the summer. The problem i see here is that some of the fine-tuning is not only about finding good values for the parameters, but also determining what parameters should be used at all, and how will they interact with other versions of the glyphs and general architecture. However, your concerns are valid; i've modified the schedule so that it explicitely says "August: fine-tuning the shapes". > P.S. After seeing your choir picture, I wonder if you are related to > Graham? ;) I know nothing about any Canadian ancestors of mine, but you never know... :) How did you like my article about LilyPond's weak sides and it's future development? Do you think that my concerns are valid? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: templates and a little bit more
On Thu, Apr 5, 2012 at 7:37 PM, Jan-Peter Voigt wrote: > Dear community, > > I bundled some extensions in a little package to try out. Some of these > ideas might be interesting to include in lily. > Here is a start of some docs, but just a little bit. I am working on it ... > http://www.xn--schne-noten-tfb.de/?tabs=3,1 I'm sorry that i don't have time to dig deeper, but my first impression is that it's somewhat similar to OrchestralLily: http://lac.linuxaudio.org/2010/papers/25.pdf http://reinhold.kainhofer.com/orchestrallily/A-simple-example.html#A-simple-example - it may give you some inspiration. Generally speaking, i'd very much linke to simplify writing LilyPond scores. Have you read my article "LilyPond's future"? (http://news.lilynet.net/?The-LilyPond-Report-25&lang=en#lilypond_s_future) What do you think about it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
