On Sun, Apr 1, 2012 at 1:55 PM, [email protected] <[email protected]> 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 <[email protected]> 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: [email protected] 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 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 the necessary changes in the architecture. Implement the most important features - issues 2456, 2462 and 2459. 4. June 11th - June 29th: exam session on my University. GSoC activity reduced to about a dozen hours a week. 5. June 29th - July 9th: prepare to mid-term evaluation; my code should pass tests for issues 2456, 2462, 2459. 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. 8. August 1st - August 10th: writing documentation, releasing my code for wide testing in a development release. 9. August 10th - August 20th: fixing unexpected bugs. 10. August 20th: celebrating and submitting a final evaluation. Since my work is clearly divided into 14 issues, checking progress will be easy - every issue has images showing how the LilyPond output after my improvements should look like. The features are related to each other, but it is not an all-or-nothing deal. Having any subset of them implemented will stil be useful to LilyPond users. Communication: First of all, I'll use a simple rule: if I'm stuck for half an hour, I'll ask my mentor for some hints. Every 5 days I will send my mentor a report on my progress (apart from usual questions asked to him and to the whole development team). Since real-time communication is most efficient, we'll use LilyPond's IRC channel or instant messenger; possibly we'll arrange regular sessions at least one day a week. All my code will be visible all the time on a dedicated public branch(es) in our git repository. When appropriate, I will create code reviews with appspot tool for other members of the team. When there's no activity on a branch for more than a few days, everyone will be allowed to nag me. Qualification: 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 "community bonding period" - the day my proposal is accepted I start working right away. This will allow me to compensate for period of reduced activity caused by university exams; it's also possible that I will finish my project ahead of the schedule. I'm an active member of the LilyPond community - see our mailing list archive: 100 e-mails in February http://lists.gnu.org/archive/html/lilypond-devel/2012-02/threads.html. Also, see my articles and an interview in the last issue of LilyPond Report, our community newsletter: http://news.lilynet.net/?The-LilyPond-Report-25 Being accepted as GSoC student will not only enable me to spend my summer implementing this project in LilyPond: in fact, the money received will allow me to continue being involved at least until the 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. And why I'm suited to do this particular issue? I'm the librarian of 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
