Google Summer of Code
What is Google Summer of Code?
GSoC is a global program that offers students stipends to write code for free software and open source projects during the summer. It is an excellent opportunity for students to gain experience with real-world software development and make a contribution that benefits everyone. It brings new contributors to LilyPond and enables students who are already involved to become more involved. LilyPond participates in GSoC as part of the GNU project.
We have had GSoC participants in 2012 and 2015 and encourage students to apply for future summers.
If you have questions or would like to apply, send us an email on our developer mailing list (see コンタクト).
Project Ideas List
Below is a list of suggested projects for GSoC or for anyone who is interested in helping to improve LilyPond. (Last updated: February 2016)
Mentor availability varies from project to project and from year to year. Send us an email on our developer mailing list (see コンタクト), and we will help you find a mentor for a project that fits your interests and skills.
If you have ideas for a GSoC project that is not listed below you can send us an email as well. There are a number of areas where LilyPond could be improved, and our development team is always willing to help those who would like to tackle a project like those listed below.
A full list of all the current open issues can be found here.
Improve internal chord structure
The internal representation of LilyPond chords is not powerful enough to capture the nomenclature of jazz chords. Currently the chord has a root, a bass and an inversion. It would be nice to be able to handle stacked or polychords, minor/major, etc. In order to do this, an internal representation with the ability to capture the essence of complex chords must be developed. As a bonus, once the internal representation is developed, the output formatting of chord names can be improved.
Difficulty: Easy/medium Requirements: Scheme (Guile), but the level necessary can be easily learned Recommended: Chord theory and naming Mentor: Carl Sorensen
ScholarLY
ScholarLY is a library in openLilyLib that provides functionality for annotating scores, making it possible to manage scholarly workflows completely in the context of the score document. So far it is possible to enter annotations of different types, produce clickable messages in the console output and export to text and LaTeX files.
There are numerous feature requests to turn this library into an even more powerful and comprehensive tool. Some examples: Inserting music examples, producing footnotes, automatically applying styles to the annotated item (e.g. dash a slur, parenthesize an accidental), creating reports with point-and-click entries. For a full description of this project suggestion please visit this Wiki page.
Difficulty: medium Requirements: Scheme, possibly LaTeX, (optionally Python) Recommended: Experience with or interest in scholarly edition and collaborative workflows. Mentor: Urs Liska
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: Werner Lemberg
Grace notes
Fix problems with synchronization of grace notes. Grace notes can interfere with LilyPond’s timing and cause odd effects, especially when multiple staffs are used where some have grace notes and others don’t. This is one of the longest-standing and one of the more embarrassing bugs in LilyPond.
Difficulty: medium Requirements: C++, MIDI Recommended: familiarity with LilyPond internals Potential Mentors: Mike Solomon (not available for GSoC 2016), Carl Sorensen
Improve default beam positioning
For regular, cross-staff, broken and kneed beams. Beaming should depend on context and neighbor notes (see section 2.2 of this book). If possible also reduce beaming-computation time.
Difficulty: medium Requirements: C++, experience with writing heuristics Recommended knowledge: aesthetic sense Potential Mentors: Mike Solomon (not available for GSoC 2016), Carl Sorensen
Allow spanners to cross voices
Currently all sorts of spanners (ties, slurs, dynamics, text spanners, trills etc.) have to be ended in the context they were started. However, this doesn’t reflect the reality of notation in most polyphonic settings. Awkward workarounds with hidden voices are currently necessary to achieve cross-voice spanners.
New ways of addressing this issue should be explored, for example by
- specifying a “target context” where the end of the spanner is expected
- explicitly specifying the ending object with an ID
This feature would solve many problems that are commonly faced with piano music and combined parts.
Difficulty: medium (?) Requirements: C++, Scheme Potential Mentor: Urs Liska
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++ Potential Mentors: Reinhold Kainhofer (not available for GSoC 2016), Joe Neeman
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.
There are several possibilities for this project, including building upon the MusicXML export project from GSoC 2015.
Difficulty: medium Requirements: MusicXML, Python, Scheme, basic LilyPond knowledge Potential Mentors: Reinhold Kainhofer, Mike Solomon (both not available for GSoC 2016)
Familiarity with other scorewriters (for cross-testing) would also help.
Improve slurs and ties
The engraving quality of slurs and ties is 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 Potential Mentors: Mike Solomon, Janek Warchoł (both not available for GSoC 2016)
他の言語: English, deutsch, español, français, italiano, nederlands
About automatic language selection.