lilypond-web: GSoC 2012
GSoC 2012
=========
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.
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 GNU project
(http://www.gnu.org/); we hope to participate in future editions as
well.
Our 2012 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.
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
here (http://code.google.com/p/lilypond/issues/list).
Grace notes
-----------
Fix problems with synchronization of grace notes, together with all
underlying architecture (see issue 34 in our tracker
(http://code.google.com/p/lilypond/issues/detail?id=34)). 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.
*Difficulty:* medium
*Requirements:* C++, MIDI
*Recommended:* familiarity with LilyPond internals
*Mentor(s):* Mike Solomon, Carl Sorensen
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:
• Handle basic musical content export like the MIDI export (i.e.
using dedicated exporter classes, derived from the translator
class)
• Build the XML tree of the basic musical content, add a connection
from music event to XML tag
• Let all LilyPond engravers do their job
• 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)
• Add a XML output backend, which can then add the layout information
for each output object to the XML tags
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.
*Difficulty:* medium
*Requirements:* MusicXML, Python, basic LilyPond knowledge
*Mentor(s):* Reinhold Kainhofer, Mike Solomon
Familiarity with other scorewriters (for cross-testing) would be a
nice bonus.
Improve slurs and ties
----------------------
The default shape of slur and tie curves is often unsatisfactory. Ties
on enharmonic notes ‘{ 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.
*Difficulty:* hard
*Requirements:* C++, experience with writing heuristics
*Recommended knowledge:* LilyPond knowledge, aesthetic sense
*Mentor(s):* Mike Solomon
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.
*Difficulty:* easy
*Requirements:* MetaFont, C++, good eye for details
*Recommended knowledge:* basic LilyPond knowledge
*Mentor(s):* Werner Lemberg
Improve beaming
---------------
Default positioning of regular, cross-staff, broken and kneed beams
should be improved. Beaming should depend on context and neighbor notes
(see section 2.2 here
(http://icking-music-archive.org/lists/sottisier/sottieng.pdf)). If
possible, reduce beaming computation time.
*Difficulty:* medium
*Requirements:* C++, experience with writing heuristics
*Recommended knowledge:* aesthetic sense
*Mentor(s):* Mike Solomon, Carl Sorensen
Clean up various compilation warnings
-------------------------------------
Clean up compiler warnings, static code analysis, and valgrind warnings.
Automatic code analysis tools (warnings in ‘g++’ and ‘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.
*Difficulty:* medium
*Requirements:* C++
*Mentor(s):* Joe Neeman, Reinhold Kainhofer
Info Catalog
lilypond-web: Development
lilypond-web: Community
lilypond-web: Authors