@ref{Development}: for contributors and testers.
@item
-@ref{GSoC 2012}: our ideas for 2012 edition of Google Summer of Code.
+@ref{Google Summer of Code}: ideas for Google Summer of Code (GSoC).
@item
@ref{Authors}: the people who made LilyPond what it is today.
* Help us::
* Sponsoring::
* Development::
-* GSoC 2012::
+* Google Summer of Code::
* Authors::
* Acknowledgements::
* Publications::
Once your bug report has been sent to the list, our Bug Squad will
examine it; they may ask you for more information. You will be notified
-when the report will be added to the bug tracker. Please allow up to 4 days,
-as we have a limited number of volunteers for this task.
+when the report will be added to the bug tracker. Please allow up to 4
+days, as we have a limited number of volunteers for this task.
Once a bug has been added to the tracker, you can comment it to add
more information about it.
You may also mark the bug so that you automatically receive emails when
-any activity on the bug occurs. This requires you have a google
-account.
+any activity on the bug occurs. This requires you have a google account
+login.
@divEnd
@divClass{column-center-bottom}
-@node GSoC 2012
-@unnumberedsec GSoC 2012
+@node Google Summer of Code
+@unnumberedsec Google Summer of Code
@divClass{column-center-top}
@subheading What is Google Summer of Code?
-It is a global program run by Google that offers students stipends
-for working on open source software projects during summer vacations.
+A global program run by Google that offers students stipends for working
+on open source software projects during summer vacations.
-The LilyPond Team decided that this is an excellent opportunity to find
-new contributors and encourage students already participating in LilyPond
-development to become more involved. One of our contributors was accepted
-for 2012 edition of the program as part of the
-@uref{http://www.gnu.org/, GNU project};
-we hope to participate in future editions as well.
+It is an excellent opportunity to find new contributors, and encourage
+students already participating in LilyPond development, to become more
+involved. One of our contributors was accepted in the 2012 program as
+part of the @uref{http://www.gnu.org/, GNU project}; and we are always
+looking for others to participate in future programs.
@divEnd
@divClass{column-center-bottom}
-@subheading Our 2012 Ideas List
+@subheading Our Ideas List
-Below is a list of projects that we suggested for GSoC 2012 students.
-Although the application period is over, we decided to keep this webpage
-online as an inspiration for anyone who is interested in developing LilyPond.
-Some members of the development team are willing to help people who would like
-to tackle these projects.
+Below is a list of projects that were suggested for the GSoC 2012
+students and is retained here as an inspiration for anyone
+who is interested in developing LilyPond for future GSoC projects.
-Of course, there are many more things to improve in LilyPond, including
-very small ones. A full list of all known issues can be found
+There are many more things that can be done to improve LilyPond and
+members of the LilyPond development team are always willing to help
+those who would like to tackle projects such as those listed below.
+
+A full list of all the current open issues can be found
@uref{http://code.google.com/p/lilypond/issues/list, here}.
@subheading Grace notes
-Fix problems with synchronization of grace notes,
-together with all underlying architecture (see
-@uref{http://code.google.com/p/lilypond/issues/detail?id=34,
-issue 34 in our tracker}). Grace notes are confusing to LilyPond's
-timing because they're like going back in time. This causes weird
-effects, especially when one staff has a grace note and the other
-doesn't.
+Fix problems with synchronization of grace notes. Grace notes can
+intefere with LilyPond's timing and cause odd effects, especially when
+multiple staffs are used where some have grace notes and others don't.
@strong{Difficulty:} medium
-
@strong{Requirements:} C++, MIDI
-
@strong{Recommended:} familiarity with LilyPond internals
-
@strong{Mentor(s):} Mike Solomon, Carl Sorensen
@subheading MusicXML
-Adding comprehensive MusicXML export and improving import,
-together with tests checking that it works. Depending on time available,
-implement some or all of the following:
+Improving MusicXML import and export functions:
@divClass{keep-bullets}
@itemize
@item
Handle basic musical content export like the MIDI export (i.e. using
-dedicated exporter classes, derived from the translator class)
+dedicated exporter classes, derived from the translator class).
@item
-Build the XML tree of the basic musical content,
-add a connection from music event to XML tag
+Build the XML tree of the basic musical content, add a connection from
+music event to XML tag.
@item
-Let all LilyPond engravers do their job
+Let all LilyPond engravers do their job.
@item
-Add ability to link each output object
-(basically each stencil / group of stencils) to the music cause
-(and thus to the XML tag in the XML tree)
+Link each output object (i.e. each stencil or group of stencils) to the
+music cause (and thus to the XML tag in the XML tree).
@item
-Add a XML output backend, which can then add the layout information
-for each output object to the XML tags
+Add an XML output backend, which can then add layout information for
+each output object to the XML tags.
@end itemize
@divEnd
-The goal will be considered achieved when a (previously chosen) score
-could be imported from MusicXML and exported back with no unintentional
-loss of data.
-
@strong{Difficulty:} medium
-
@strong{Requirements:} MusicXML, Python, basic LilyPond knowledge
-
@strong{Mentor(s):} Reinhold Kainhofer, Mike Solomon
-Familiarity with other scorewriters (for cross-testing) would be a nice
-bonus.
+Familiarity with other scorewriters (for cross-testing) would also help.
+
@subheading Improve slurs and ties
-The default shape of slur and tie curves is often unsatisfactory.
-Ties on enharmonic notes @code{@{ cis'~ des' @}} are not supported,
-ties "broken" by clef or staff change aren't supported well.
-The project includes collecting and sorting examples of bad output,
-deciding on the intended output and writing the actual code.
+The default curves of slurs and ties are often unsatisfactory. Ties
+@q{broken} by clef or staff changes are not handled well. The project
+could include collecting and sorting examples of bad output, deciding on
+the intended output and writing code to improve them.
@strong{Difficulty:} hard
-
@strong{Requirements:} C++, experience with writing heuristics
-
@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
-
@strong{Mentor(s):} Mike Solomon
-@subheading Adding special variant of font glyphs
-Adding on-staff-line, between-staff-line, shorter and narrower variants
-of some glyphs, for example accidentals, together with a generic
-infrastructure to support them. An example is ancient notation breve
-notehead coming in two variants, with smaller and bigger hole.
+@subheading Adding variants of font glyphs
-@strong{Difficulty:} easy
+@divClass{keep-bullets}
+@itemize
-@strong{Requirements:} MetaFont, C++, good eye for details
+@item
+Adding @q{on} and @q{between} staff-line variants.
-@strong{Recommended knowledge:} basic LilyPond knowledge
+@item
+Shorter and narrower variants of some glyphs for example, accidentals.
+Another, more specific example could be an ancient notation breve
+notehead coming in two variants one with a small or big @q{hole} within
+it.
+
+@end itemize
+@divEnd
+@strong{Difficulty:} easy
+@strong{Requirements:} MetaFont, C++, good eye for details
+@strong{Recommended knowledge:} basic LilyPond knowledge
@strong{Mentor(s):} Werner Lemberg
-@subheading Improve beaming
+@subheading Improve default beam positioning
-Default positioning of regular, cross-staff, broken and kneed beams
-should be improved. Beaming should depend on context and neighbor notes
+For regular, cross-staff, broken and kneed beams. Beaming should depend
+on context and neighbor notes
(see @uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf,
-section 2.2 here}). If possible, reduce beaming computation time.
+section 2.2 here}). If possible also reduce beaming-computation time.
@strong{Difficulty:} medium
-
@strong{Requirements:} C++, experience with writing heuristics
-
@strong{Recommended knowledge:} aesthetic sense
-
@strong{Mentor(s):} Mike Solomon, Carl Sorensen
-
@subheading Clean up various compilation warnings
-Clean up compiler warnings, static code analysis, and valgrind warnings.
-Automatic code analysis tools (warnings in @code{g++} and @code{clang})
-and analysis tools like valgrind memory leak detection and callgrind
-code profilers provide valuable information about possible flaws in C++
-code. Cleaning these warnings would allow us to automatically reject
-any patch which introduced extra warnings.
+@subheading Help improve compilation behavior
-@strong{Difficulty:} medium
+Automatic code analysis tools, like valgrind memory leak detection or
+callgrind code profilers, provide valuable information about possible
+flaws in our C++ code. Cleaning up warnings would allow us to automate
+the rejection of any patch which introduced extra warnings.
+@strong{Difficulty:} medium
@strong{Requirements:} C++
-
@strong{Mentor(s):} Joe Neeman, Reinhold Kainhofer
@divEnd
-
-
@node Authors
@unnumberedsec Authors
projects / lilypond.git / commitdiff