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 <[email protected]> 2012-04-01 11:14:05 Committer: Mike Solomon <[email protected]> 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 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]; 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 @@ -67,15 +76,18 @@ 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 - June 10th: do necessary changes in architecture. +3. May 7th - June 10th: do the necessary changes in the architecture. Implement the most important features - issues 2456, 2462 and 2459. 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.] 5. June 29th - July 9th: if everything is on schedule, I may take a week of vacation. However, if there are any doubts if everything goes as planned, I don't go anywhere. Prepare to mid-term evaluation; my code should pass tests for issues 2456, 2462, 2459. +[This should also be gotten rid of.] 6. July 9th - July 13th: submit mid-term evaluation. 7. July 13th - August 1st: have working code for at least 12 out of 14 project issues. @@ -107,7 +119,7 @@ will be allowed to nag me. Qualification: -I'm working on LilyPond for more than a year now; there are about 60 +I've been working on LilyPond for more than a year now; there are about 60 commits of mine in the official repository. I know people in the community, including my mentor, and they know me and value my work. I know how the development process looks like, so I don't need the @@ -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). +hours a week in the following months. And why I'm suited to do this particular issue? I'm the librarian of -the Epifania choir in which I sing bass, so I regularly typeset vocal -scores. Virtually every one of my several dozen scores will benefit -from implementing this feature. Also, as I've already said, it was me -who prepared the Lyrics Bug Report; I was collecting scanned examples -of published scores for a long time and I know how this stuff should -work like. \ No newline at end of file +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. _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
