Google Summer of Code
Note : Dans la mesure où les développeurs de LilyPond sont disséminés sur la planète et que la participation au programme estival de Google requiert l’utilisation de l’anglais, il n’est pas prévu de traduire les paragraphes qui suivent.
What is Google Summer of Code?
GSoC is a global program that offers stipends to contributors to write code for free software and open source projects. Within a flexible time frame of three months or more, contributors work to complete a given task as part of the project’s community and under the guidance of experienced mentors. The program is an excellent opportunity for students and non-professionals to gain experience with real-world software development and make a contribution that benefits everyone. It brings new contributors to LilyPond and enables people who are already involved to become more involved. LilyPond participates in GSoC as part of the GNU project.
We had GSoC participants in 2012, 2015, 2016, 2017 and 2020. This site is current for the 2023 program.
Project Ideas List
Below is a list of GSoC project ideas, but if you have other ideas for a project you are welcome to make a suggestion on our developer mailing list (see section Contact). 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 similar to those listed below. As mentor availability varies from project to project and from year to year it is wise to get in touch with us as early as possible.
Note that we also have « Community Mentors ». We aim at assigning one Community Mentor to each active project who is not responsible for discussing the implementation or reviewing the code. Instead they will on the one hand discuss the design of the planned features from the (power) user perspective, and they will look after the communication between participant and mentor, and between the two and the community.
A full list of all the current open issues can be found here.
Adding more glyphs to LilyPond’s Emmentaler music font
- More SMuFL glyphs
The World Wide Web (W3C) consortium has been maintaining the Standard Music Font Layout (SMuFL) with a reference font called Bravura since a few years; this font contains a large amount of glyphs not part of LilyPond’s Emmentaler music font. A mapping between LilyPond glyph names and SMuFL glyph names and encoding can be found in this ongoing project.
- ‘On’ and ‘between’ staff-line variants
For some glyphs it would be beneficial to have different glyphs, depending on whether they sit on a staff line or between two staff lines. Examples are shaped note heads.
- Shorter and narrower variants of some glyphs
For tight typesetting situations (i.e., only a small amount of horizontal space is available) it would help to have glyph variants that need less horizontal space, for example narrower accidentals (issues #2141ff). Another, more specific example could be an ancient notation breve notehead coming in two variants (with a smaller or bigger ‘hole’).
Difficulty: easy to medium
Requirements: MetaFont/MetaPost, C++, good eye for details
Recommended knowledge: basic LilyPond knowledge
Size: 175h/350h, depending on the selected sub-tasks
Mentor: Werner Lemberg
Improve/Extend Export to MusicXML
There is experimental support for exporting scores to MusicXML. So far there is limited coverage that should be extended, and the export should become more robust with regard to unconventionally organized input files. Several strategies can be thought of in that regard.
Significant progress in coverage has been made in a GSoC Project hosted by Frescobaldi in 2017, but there is still much to be done that could make a nice GSoC project.
Working in this project will mainly be done in the python-ly repository.
Difficulty: easy to hard (depending on the targeted improvements)
Size of project: 175h/350h
Requirements: Python, MusicXML
Mentor: Peter Bjuhr (?)
Fix Beaming Patterns/Beam Subdivisions and Tuplets
Subdivision is an important way to improve the readability of beamed music. However, despite several attempts at fixing it LilyPond still does not always produce correct results. In order to properly fix this issue it seems necessary to rewrite the responsible code from the ground up. Much work has already been done assessing the issue (see this discussion and issue #5547).
In the course of this assessment it has been found that LilyPond’s conception of tuplets is somewhat flawed as well (see this discussion), and that this has to be fixed as well.
Size of project: 350h
Recommended knowledge: Good musical and mathematical understanding of timing issues
Mentors: Carl Sorensen (?)
Support for Style Sheets
LilyPond’s engraving output can be tweaked to the least detail, and one important addition in recent years was the ability to use alternative notation fonts. It is possible to create reusable modules for « house styles », but this project aims at bringing this to a new level by creating a convenient extension package with support for creating, applying, and sharing modular style sheets. We are looking for a hierarchical structure that allows to mix and match style elements for « house » (e.g., « my-personal-style », « client-a », « client-b », etc.), score type, paper size, etc.
Work can be built upon the existing notation-fonts openLilyLib package. We would like to see a further improvement of the loading mechanism for notation fonts (for example, a better separation of loading notation and text fonts) as part of the project, and optionally (this would involve working on Lilypond’s C++ code) support for notation fonts that are installed system-wide.
Size of project: 175h/350h
Requirements: Scheme, aesthetic competence
Recommended: sense of building hierarchical frameworks
Optional: C++ (for font loading internals)
Mentor: Abraham Lee (?)
Community Mentor: Kieren MacMillan
Information for Applicants/Participants
For all GSoC issues related to LilyPond, please contact our ‘lilypond-devel’ mailing list (see section Contact)!
In order to have a satisfying experience with GSoC applicants are strongly advised to thoroughly read the following recommendations. Some of these are relevant for the application process, others for the time within the project.
- Read all applicable information on the program’s website, particularly the students’ manual. Make sure you fulfill all of Google’s prerequisites and are willing to join the program as specified.
- Please get in touch with us as soon as possible if you are interested in applying with a project. Mentor availability may change without notice, project proposals may need fine-tuning, and many other reasons might require us to reject or ignore an application that hasn’t been discussed before.
- We do not know in advance how many « slots » we will have available for projects, so please be aware that you may find yourself in competition with other applicants or not. Interested or even enthusiastic response from our mentors is no guarantee of eventually being accepted, and not being accepted does not necessarily indicate a negative evaluation of your application. If we have to decide between different applicants there may be various aspects to consider.
- Integration in the LilyPond community is a fundamental part of GSoC, and we expect our participators to make substantial efforts to become community members. Within the bonding period we expect you to be active on our mailing lists, introducing yourself but also communicating about unrelated tasks. This goes beyond the mere setting up of a working environment and familiarizing yourself with the relevant code, but we think it is crucial for the GSoC project to be mutually satisfying.
- If you are accepted to the program you will have one mentor explicitly assigned to your project. With this mentor you will have to agree upon a communication strategy, be it emails, chatrooms, issue trackers or voice/video chats. Regular communication is absolutely crucial for the success of a GSoC project so you are stricly required to keep talking to your mentor. But keep in mind that your mentor has explicitly taken over the responsibility for your project, and while unlike you he isn’t paid for this activity you are still entitled to get regular attention from him.
- In order to get support from your mentor you have to give him a chance to follow your progress and efforts. Therefore it is important to regularly commit your changes to the versioning repository you are working on. Don’t hesitate making unfinished code available because you are afraid of criticism, and don’t suppress questions because you think they might be considered stupid. But ideally your code should at any time be accompanied by compatible testing code. Your mentor may not be able to properly assess your code by only reading it without the opportunity to apply it in a real example.
There is a list of inactive projects in the Grenier. We list projects there that are still considered valuable but for which there are currently no mentors available.