[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: my GSoC application - please review! (also, who will be my mentor?)

From: Janek Warchoł
Subject: Re: my GSoC application - please review! (also, who will be my mentor?)
Date: Mon, 2 Apr 2012 17:05:44 +0200

On Sun, Apr 1, 2012 at 1:55 PM, address@hidden
<address@hidden> 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 <address@hidden> 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!

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:

The name of the project:
LilyPond: improve Lyrics support

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.

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.

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:
(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
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"

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.

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.

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
 Also, see my articles and an interview in the last issue of LilyPond
Report, our community newsletter:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]