Google Summer of Code
What is Google Summer of Code?
A global program run by Google that offers students stipends for working on open source software projects during summer vacations.
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 GNU project; and we are always looking for others to participate in future programs.
Our Ideas List
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.
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 here.
Grace notes
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.
Difficulty: medium Requirements: C++, MIDI Recommended: familiarity with LilyPond internals Mentor(s): Mike Solomon, Carl Sorensen
MusicXML
Improving MusicXML import and export functions:
- 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.
- 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).
- Add an XML output backend, which can then add layout information for each output object to the XML tags.
Difficulty: medium Requirements: MusicXML, Python, basic LilyPond knowledge Mentor(s): Reinhold Kainhofer, Mike Solomon
Familiarity with other scorewriters (for cross-testing) would also help.
Improve slurs and ties
The default curves of slurs and ties are often unsatisfactory. Ties ‘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.
Difficulty: hard Requirements: C++, experience with writing heuristics Recommended knowledge: LilyPond knowledge, aesthetic sense Mentor(s): Mike Solomon
Adding variants of font glyphs
- Adding ‘on’ and ‘between’ staff-line variants.
- 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 ‘hole’ within it.
Difficulty: easy Requirements: MetaFont, C++, good eye for details Recommended knowledge: basic LilyPond knowledge Mentor(s): Werner Lemberg
Improve default beam positioning
For regular, cross-staff, broken and kneed beams. Beaming should depend on context and neighbor notes (see section 2.2 here). If possible also reduce beaming-computation time.
Difficulty: medium Requirements: C++, experience with writing heuristics Recommended knowledge: aesthetic sense Mentor(s): Mike Solomon, Carl Sorensen
Help improve compilation behavior
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.
Difficulty: medium Requirements: C++ Mentor(s): Joe Neeman, Reinhold Kainhofer
他の言語: deutsch, français, italiano, nederlands
About automatic language selection.