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 ([email protected]) 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: [email protected] 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 - June 10th: do necessary changes in 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. 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. 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'm 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: link to be pasted. 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. 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). 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. _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
