Re: my GSoC application - please review! (also, who will be my mentor?)
Le 03/04/2012 23:17, Janek Warchoł disait : On Mon, Apr 2, 2012 at 5:10 PM, m...@apollinemike.com m...@apollinemike.com wrote: Looks good! It's much more assertive and professional it's an easier read as well. Good luck! The application should now be publicly visible here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/janek_warchol/1# Typos : Third paragraph in Deliverables - the gap between neighbor obejcts, the difference + the gap between neighbor objects, the difference Otherwise, it looks like a nice trip for you summer vacations! Cheer, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On Thu, Apr 5, 2012 at 7:46 PM, Jean-Charles Malahieude lily...@orange.fr wrote: Le 03/04/2012 23:17, Janek Warchoł disait : http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/janek_warchol/1# Typos : Third paragraph in Deliverables - the gap between neighbor obejcts, the difference + the gap between neighbor objects, the difference thanks, fixed! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On Mon, Apr 2, 2012 at 5:10 PM, m...@apollinemike.com m...@apollinemike.com wrote: Looks good! It's much more assertive and professional it's an easier read as well. Good luck! The application should now be publicly visible here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/janek_warchol/1# Please note that i've changed the schedule, and also added a skill evaluation as requested by GNU. I've also added some pictures - what do you think about them? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On 4/3/12 3:17 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: The application should now be publicly visible here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/janek_w archol/1# Please note that i've changed the schedule, and also added a skill evaluation as requested by GNU. I've also added some pictures - what do you think about them? cheers, Janek LGTM. I don't know that it makes any difference, but you should do s/thourough/thorough/ Great job! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On Wed, Apr 4, 2012 at 12:08 AM, Carl Sorensen c_soren...@byu.edu wrote: I don't know that it makes any difference, but you should do s/thourough/thorough/ fixed. Great job! Thanks! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On Sun, Apr 1, 2012 at 1:55 PM, m...@apollinemike.com m...@apollinemike.com wrote: It's just the opposite - the use of technical details shows a lack of clarity of understanding, as it attaches importance to things that may change depending on the implementation as opposed to design. Stay on the design level. I'd define early on the concepts of engraver and grob and then use them as a ritornello. GNU is not there to finance other LilyPond developers - they're there to finance you. You need to be confident and assertive and sell yourself. They need to have the impression that you know exactly what you're doing, know exactly how you're going to go about it, and that you're worth every penny of what you're going to do. Many thanks for the tips, Mike! I attach the revised application at the bottom, and i will submit it later today (applications can be edited until deadline). On Mon, Apr 2, 2012 at 2:05 AM, Carl Sorensen c_soren...@byu.edu wrote: I think you should be selected for GSoC. You clearly meet all of the important metrics, and your work will be important for LilyPond. Thanks for encouragement, Carl! I agree with everybody else's comments. I would be willing to be your backup mentor. Thank you, i'm honoured! Janek Revised application: My name: Jan Warchoł (I usually use form Janek to distinguish myself from Jan Nieuwenhuizen in LilyPond community) I study mechatronics on Warsaw University of Technology (first year). I studied math for 2 years. My email address: janek.lilyp...@gmail.com The name of the project: LilyPond: improve Lyrics support Summary: LilyPond support for lyrics (words that are sung to the melody - usually each syllabe is placed under it's respective note) is currently similar to that of the two market leaders (Finale and Sibelius) - users can add any number of lyric verses in any language supported by UTF-8 encoding. I want to add advanced lyric positioning functions that will be unique to LilyPond; syllabes will be automatically moved to faciliate easier sight reading for singers and avoid any ambiguities in interpretation. Lyric syllabes will no longer casuse disturbances in note spacing - instead of moving notes to fit lyrics, lyrics will adapt their position to allow for the optimal note spacing. Benefits: Users will have their lyrics automatically typeset with a quality equal to that of the best hand-engraved professional publications; LilyPond's default lyric positioning will surpass that of any other music notation program (including world market leaders such as Finale and Sibelius). There will be virtually no need for hard-coded manual corrections, making scores easier to maintain and rearrange. The GNU project will benefit from having a music engraving program offering its users unique possibilities and a very efficient workflow. LilyPond is already delivering great typography, but producing professional scores of such works as G. F. Handel's Messiah still requires some manual corrections; better lyric positioning is one of the few improvements needed to have LilyPond automatically produce publication-quality scores of great works. Deliverables: I've prepared a detailed report on the features that are needed, putting each feature into a separate issue for greater clarity. The issues are viewable in LilyPond's bug tracker: http://code.google.com/p/lilypond/issues/list?q=label:GSoC-LyricProject (so even if my application isn't accepted the community will benefit by having a thourough report on the matter). These features shouldn't be addressed separately; they are connected to each other and a good solution must be based on a generic architecture. I will add new properties to Lyric objects, and also ensure that when LilyPond calculates position of lyrics, she already knows how the notes should be placed to achieve best results. Thus, while most of the changes will affect Lyrics class, fixing issues 2462 and 2450 will require modifications to horizontal note spacing algorithm. As for issue 2459, I will add a new type of context - a line that can be broken into segments. I will then add a command that will allow users to choose breaking points - that's an easy thing to do. Then, when I finish other issues, I'll add advanced functionalities: automatic breaking based on the gap between neighbor obejcts, the difference between vertical baseline position, and overall vertical tightness of music. All new features will have regresstion tests. Most of the tests are already written - they're now added as examples in tracker issues. Documentation - I'll have to list and describe new object properties, contexts and functions in Internals Reference. I'll explain how to use new possibilities in notation reference, section 2.1.2 Techniques specific to lyrics Plan: 1. April 20th - May 1st: discuss general architecture design with my mentor; list object properties and methods that need to be created. Determine how to harvest information about
Re: my GSoC application - please review! (also, who will be my mentor?)
On Apr 2, 2012, at 5:05 PM, Janek Warchoł wrote: On Sun, Apr 1, 2012 at 1:55 PM, m...@apollinemike.com m...@apollinemike.com wrote: It's just the opposite - the use of technical details shows a lack of clarity of understanding, as it attaches importance to things that may change depending on the implementation as opposed to design. Stay on the design level. I'd define early on the concepts of engraver and grob and then use them as a ritornello. GNU is not there to finance other LilyPond developers - they're there to finance you. You need to be confident and assertive and sell yourself. They need to have the impression that you know exactly what you're doing, know exactly how you're going to go about it, and that you're worth every penny of what you're going to do. Many thanks for the tips, Mike! I attach the revised application at the bottom, and i will submit it later today (applications can be edited until deadline). Looks good! It's much more assertive and professional it's an easier read as well. Good luck! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
my GSoC application - please review! (also, who will be my mentor?)
Hi all, below is my application, written according to GNU guidelines (http://www.gnu.org/software/soc-projects/guidelines.html). What do you think about it? Also, since this is a new project not mentioned on our GSoC page, i need to know who will mentor me - Mike? :) (it would be great if someone also decided to be a backup mentor just in case) Apart from guiding me during my work on the project, the mentor is supposed to review my application, submit mid-term and final evaluations of my work to Google and talk with GNU, our umbrella organization. Since the number of student slots is limited and there are many free software projects in the umbrella, it may be necessary to convince GNU administrator Jose Marchesi (jema...@gnu.org) that it's absolutely essential that he chooses LilyPond applications over other projects (actually, i think that everyone, especially our administrator Graham, Han-Wen and Jan, can take part in convincing Jose :D) Thanks! Janek My name: Jan Warchoł (I usually use form Janek to distinguish myself from Jan Nieuwenhuizen in LilyPond community) My email address: janek.lilyp...@gmail.com The name of the project: LilyPond: improve Lyrics support Summary: LilyPond support for lyrics is currently similar to the two market leaders (Finale and Sibelius) - users can add any number of lyric verses, in any language supported by UTF-8 encoding. I want to add advanced lyric positioning functions that will be unique to LilyPond: syllabes will be automatically moved to faciliate easier sight reading for singers and avoid any ambiguities in interpretation. Lyric syllabes will no longer casuse disturbances in note spacing - instead of moving notes to fit lyrics, lyrics will adapt their position to allow for the optimal note spacing. Benefits: Users will have their lyrics automatically typeset in quality equal to best hand-engraved professional publications; LilyPond's default lyric positioning will surpass any other music notation program (including world market leaders Finale and Sibelius). There will be virtually no need for hard-coded manual corrections, so the scores will be easier to maintain and rearrange. GNU project will benefit by having a music engraving program offering its users unique possibilities and very efficient workflow. LilyPond is already delivering great typography, but producing professional scores of such works as G. F. Handel's Messiah still requires some manual corrections; better lyrics positioning is one of the few improvements needed to have LilyPond automatically produce publication-quality scores of such great works. Deliverables: I've prepared a detailed report on the features that are needed, putting each feature into separate issue for greater clarity. It is available in LilyPond's bug tracker: http://code.google.com/p/lilypond/issues/list?q=label:GSoC-LyricProject (so even if my application isn't accepted the community will benefit by having a thourough report on the matter). Of course these features shouldn't be addressed separately; they are connected to each other and a good solution must provide a generic architecture. I suggest to add some new properties to LyricText grobs, for example a right- and left-alignment edge (would solve issues 2451 and 2452). I'll investigate how much of the formatting process can be done after line-breaking is calculated, as it would be best to know where lines are broken and how much space is available for each notehead before calculating alignment of lyric syllabes. However, if this turns out to be impossible, I'll estimate measure width and place syllabes according to worst-case scenario, and then adjust their position after line breaking is done. Most of the changes will be done Lyric_engraver class; however, fixing issues 2462 and 2450 will require modifications to horizontal spacing algorithm itself. As for issue 2459, the plan is to add a new type of context - a breakable line. I will then add a command that will allow users to choose breaking points - that's an easy thing to do. Then, when I finish other issues, I'll add automatic breaking based on the gap between neighbor obejcts, the difference between vertical baseline position, and overall vertical tightness of music. All new features will have regresstion tests. Most of the tests are already written - they're now added as examples in tracker issues. Documentation - I'll have to list and describe new object properties, contexts and functions in Internals Reference. I'll explain how to use new possibilities in notation reference, section 2.1.2 Techniques specific to lyrics Plan: 1. April 20th - May 1st: discuss general architecture design with my mentor; list grob properties and methods that need to be created. Determine how to harvest information about horizontal spacing and whether any changes in horizontal spacing engine will be necessary. 2. May 1st - May 7th: discuss results of the previous step with whole development team. 3. May 7th -
Re: my GSoC application - please review! (also, who will be my mentor?)
Janek, please do s/syllabe/syllable/ Besides this, it looks nice, and hopefully everything runs fine! BTW, expect delays with the schedule :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On Apr 1, 2012, at 9:39 AM, Janek Warchoł wrote: Also, since this is a new project not mentioned on our GSoC page, i need to know who will mentor me - Mike? :) Doable, although if I mentor you you may wind up breaking more things than you fix! Below is a diff with some corrections. It's very well written. Besides what I wrote below, three general comments: --) speak more assertively --) speak more confidently --) use less technical terms Cheers, MS Author: Mike Solomon m...@apollinemike.com 2012-04-01 11:14:05 Committer: Mike Solomon m...@apollinemike.com 2012-04-01 11:14:05 Parent: c35f566640d51950684263bc18e82dc60914d41d (initial proposition) Branch: master Follows: Precedes: corrections --- prop.txt --- index 7c87774..8342069 100644 @@ -1,41 +1,44 @@ Summary: -LilyPond support for lyrics is currently similar to the two market +LilyPond support for lyrics is currently similar to that of the two market leaders (Finale and Sibelius) - users can add any number of lyric -verses, in any language supported by UTF-8 encoding. I want to add -advanced lyric positioning functions that will be unique to LilyPond: +verses in any language supported by UTF-8 encoding. I want to add +advanced lyric positioning functions that will be unique to LilyPond; syllabes will be automatically moved to faciliate easier sight reading for singers and avoid any ambiguities in interpretation. Lyric syllabes will no longer casuse disturbances in note spacing - instead of moving notes to fit lyrics, lyrics will adapt their position to allow for the optimal note spacing. +[It may be worth it here to mention what lyrics are and show several +examples of how they are written in music (handwritten, hand typeset, +computer typeset).] Benefits: -Users will have their lyrics automatically typeset in quality equal to -best hand-engraved professional publications; LilyPond's default lyric -positioning will surpass any other music notation program (including -world market leaders Finale and Sibelius). There will be virtually no -need for hard-coded manual corrections, so the scores will be easier +Users will have their lyrics automatically typeset with a quality equal to +that of the best hand-engraved professional publications; LilyPond's default lyric +positioning will surpass that of any other music notation program (including +world market leaders such as Finale and Sibelius). There will be virtually no +need for hard-coded manual corrections, making scores easier to maintain and rearrange. -GNU project will benefit by having a music engraving program offering -its users unique possibilities and very efficient workflow. LilyPond +The GNU project will benefit from having a music engraving program offering +its users unique possibilities and a very efficient workflow. LilyPond is already delivering great typography, but producing professional scores of such works as G. F. Handel's Messiah still requires some -manual corrections; better lyrics positioning is one of the few +manual corrections; better lyric positioning is one of the few improvements needed to have LilyPond automatically produce -publication-quality scores of such great works. +publication-quality scores of great works. Deliverables: I've prepared a detailed report on the features that are needed, -putting each feature into separate issue for greater clarity. It is -available in LilyPond's bug tracker: +putting each feature into a separate issue for greater clarity. The issues +are viewable in LilyPond's bug tracker: http://code.google.com/p/lilypond/issues/list?q=label:GSoC-LyricProject (so even if my application isn't accepted the community will benefit by having a thourough report on the matter). -Of course these features shouldn't be addressed separately; they are -connected to each other and a good solution must provide a generic -architecture. I suggest to add some new properties to LyricText -grobs, for example a right- and left-alignment edge (would solve +These features shouldn't be addressed separately; they are +connected to each other and a good solution must be based on a generic +architecture. I suggest the addition of new properties to LyricText +grobs, for example a right- and left-alignment edge (which would solve issues 2451 and 2452). I'll investigate how much of the formatting process can be done after line-breaking is calculated, as it would be best to know where lines are broken and how much space is available @@ -43,7 +46,13 @@ for each notehead before calculating alignment of lyric syllabes. However, if this turns out to be impossible, I'll estimate measure width and place syllabes according to worst-case scenario, and then adjust their position after line breaking is done. -Most of the changes will be done Lyric_engraver class; however, fixing +[This However and the sentence above it are too technical and too iffy. +You are in
Re: my GSoC application - please review! (also, who will be my mentor?)
On Sun, Apr 1, 2012 at 10:40 AM, Werner LEMBERG w...@gnu.org wrote: please do s/syllabe/syllable/ done, thanks! Besides this, it looks nice, and hopefully everything runs fine! BTW, expect delays with the schedule :-) i know :) On Sun, Apr 1, 2012 at 11:16 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Apr 1, 2012, at 9:39 AM, Janek Warchoł wrote: Also, since this is a new project not mentioned on our GSoC page, i need to know who will mentor me - Mike? :) Doable, although if I mentor you you may wind up breaking more things than you fix! ;) Below is a diff with some corrections. It's very well written. Besides what I wrote below, three general comments: --) speak more assertively --) speak more confidently --) use less technical terms thanks! On Fri, Mar 30, 2012 at 10:55 PM, m...@apollinemike.com m...@apollinemike.com wrote: I have a pretty good sense of how difficult each issue will be to fix - lemme know if you need an order of attack once you get cracking on these problems. Do you think i've chosen a good order of attach in my plan? My problem is that i will have significantly more time in the second half of the project. However, i've read that it's better to start with the most important (on thus often most difficult) part of the project, because it's better for mid-term evaluations. Summary: +[It may be worth it here to mention what lyrics are and show several +examples of how they are written in music (handwritten, hand typeset, +computer typeset).] Good idea. I'll investigate how much of the formatting process can be done after line-breaking is calculated, as it would be best to know where lines are broken and how much space is available @@ -43,7 +46,13 @@ for each notehead before calculating alignment of lyric syllabes. However, if this turns out to be impossible, I'll estimate measure width and place syllabes according to worst-case scenario, and then adjust their position after line breaking is done. -Most of the changes will be done Lyric_engraver class; however, fixing +[This However and the sentence above it are too technical and too iffy. +You are in competition with other candidates and you need to sound certain +of yourself. Also, for them, lign-breaking, measure width, etc. do not +mean anything. You need to use generic terms as much as possible and, when +you can, include pretty pictures.] +Most of the changes will be done Lyric_engraver class [again, not +comprehensible for someone outside of the project]; I'll try. However, GNU application guidelines say What software will be added or changed? What parts of the project's code will be affected? Which documentation will you update? When we read this section of your proposal, we will be trying to figure out how well you understand what needs to be done. We're more likely to accept proposals from students who show us that they know what needs to be done. - that's why i tried to say something about the technical details. 4. June 11th - June 29th: exam session on University. Reduced GSoC activity; writing drafts for remaining features and asking the development team for feedback and testing of my work. +[Stuff like this you can get rid of - just give the most pertinent +aspects of the plan.] You mean writing drafts and testing or mentioning my exam session? As for the exams (and the week of holidays mentioned later), GNU guidelines say Remember to mention any periods during the summer when you won't actually be available to work on the project @@ -128,19 +140,12 @@ end of 2012 (quite possibly even longer). The stipend from GSoC will cover my financial needs for at least 8 months - therefore in addition to spending at least 400 working hours on LilyPond until August 20th, I'll dedicate 40 hours a week to LilyPond in September and about 10-20 -hours a week in the following months. Otherwise (that is, if i'm not -accepted as a GSoC student) I'll have to find a part-time job, and -it's possible that I will have to stop contributing to LilyPond in the -next academic year. - -Additionally, I decided that if I suceed, I'll give $500 back to the -LilyPond community (i.e. pay one of the developers for implementing -some things that are too difficult for me to code). Why do you think i should not mention this? Is it because it's a negative message? +the Epifania choir in which I sing bass and I regularly typeset vocal +scores. I know how important legibility is in lyric typesetting and how +much clear lyrics will benefit choirs and thus music around the world. +Also, being the one who prepared the Lyrics Bug Report, I have been collecting +scanned examples of published scores for a long time and I know how to do +the necessary research and coding to implement an elegant solution. That's nice! Many thanks for your help! Janek ___ lilypond-devel mailing list
Re: my GSoC application - please review! (also, who will be my mentor?)
On Apr 1, 2012, at 1:24 PM, Janek Warchoł wrote: Do you think i've chosen a good order of attach in my plan? My problem is that i will have significantly more time in the second half of the project. However, i've read that it's better to start with the most important (on thus often most difficult) part of the project, because it's better for mid-term evaluations. Start with horizontal spacing. Always start with horizontal spacing. Everything comes down to horizontal spacing. Horizontal spacing. I'll try. However, GNU application guidelines say What software will be added or changed? What parts of the project's code will be affected? Which documentation will you update? When we read this section of your proposal, we will be trying to figure out how well you understand what needs to be done. We're more likely to accept proposals from students who show us that they know what needs to be done. - that's why i tried to say something about the technical details. It's just the opposite - the use of technical details shows a lack of clarity of understanding, as it attaches importance to things that may change depending on the implementation as opposed to design. Stay on the design level. I'd define early on the concepts of engraver and grob and then use them as a ritornello. Remember to mention any periods during the summer when you won't actually be available to work on the project Just mention the periods - don't mention why (or just put exams). The less text the better. Imagine that every word they read costs 1 unit of attention down the line for something that's really important. Why do you think i should not mention this? Is it because it's a negative message? No, because it is undercutting the worth of your work. GNU is not there to finance other LilyPond developers - they're there to finance you. You need to be confident and assertive and sell yourself. They need to have the impression that you know exactly what you're doing, know exactly how you're going to go about it, and that you're worth every penny of what you're going to do. Cheers, MS___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: my GSoC application - please review! (also, who will be my mentor?)
On 4/1/12 1:39 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: Hi all, below is my application, written according to GNU guidelines (http://www.gnu.org/software/soc-projects/guidelines.html). What do you think about it? Also, since this is a new project not mentioned on our GSoC page, i need to know who will mentor me - Mike? :) (it would be great if someone also decided to be a backup mentor just in case) Janek, I think you should be selected for GSoC. You clearly meet all of the important metrics, and your work will be important for LilyPond. I agree with everybody else's comments. I would be willing to be your backup mentor. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
