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 students stipends to write code for free software and open source projects during the summer. For three months students 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 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, 2015, 2016 and 2017. This site will be updated in time before the 2018 season will start.
Project Ideas List
Below is a list of GSoC project ideas (last update: May 2017), but if you have other ideas for a project you may complete within the three months of the program you’re welcome to make a suggestion on our developer mailing list (see 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.
A full list of all the current open issues can be found here.
Adopt the SMuFL music font encoding standard
For several years now a new standard for music fonts has been around: SMuFL, which is also discussed as becoming part of a future W3C standard for music encoding. As a FLOSS tool LilyPond should adhere to such an open standard instead of using an isolated solution like it does today. Adopting SMuFL will help integrating LilyPond with the world of music notation software and eventually give LilyPond users access to a wider selection of notation fonts.
Making LilyPond compliant to SMuFL includes remapping of the glyphs that are built from METAFONT sources, adjusting the glyphs’ metrics to SMuFL’s specifications, and finally updating the way LilyPond looks up and positions the glyphs. As an optional part of this project LilyPond’s font loading mechanism could be modified to use notation fonts installed as system fonts instead of inside the LilyPond installation.
Difficulty: Easy/medium
Requirements: C++ and willingness to get familiar with LilyPond internals.
Recommended: Interest and experience in working with font files. A little bit of METAFONT.
Mentors: Werner Lemberg, Abraham Lee
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
Contemporary Notation
LilyPond is very good at creating non-standard notation. Having to code every graphical element instead of simply drawing it may seem cumbersome but is in fact a strong asset. New notational functionality can be provided with consistent appearance, automatic layout and a natural syntactic interface.
Within the openLilyLib library system the student will create a fundamental infrastructure and building blocks to make creating contemporary notation easier. Additionally (at least) one concrete package is developed to cover specific contemporary notation, such as for example the style of a given composer, extended playing techniques for a specific instrument or a certain category of effects.
Difficulty: medium
Requirements: Scheme (interaction with LilyPond internals), contemporary notation techniques
Recommended: sense of building hierarchical frameworks
Mentors: NN, Urs Liska
Rewrite LibreOffice LilyPond Extension with Python
The OOoLilyPond extension made it possible to conveniently include LilyPond score snippets in OpenOffice.org/LibreOffice Writer, Draw and Impress documents while keeping source and image together. After many years without development an initial effort has started to make the extension compatible again with current versions of LibreOffice and LilyPond.
However, as the LibreOffice ecosystem has changed substantially it is now possible to rewrite the extension with Python and PyQt. This will not only be more powerful in general but will allow the integration of functionality from Frescobaldi, such as for example syntax highlighting, entry helpers, score wizards or musical transformations.
Difficulty: easy/medium
Requirements: Python, PyQt, LilyPond basics, LibreOffice extension basics
Recommended knowledge: Familiarity with Frescobaldi code based or willingness to learn during bonding period
Mentor(s): Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
Automated testing and documentation for openLilyLib
openLilyLib is an extension framework for LilyPond code providing a “snippets” repository and a suite of integrated packages such as for example page layout tools or scholarly annotations. It is very powerful and promising, but to really get off the ground two features are missing: automated testing and documentation generation.
Automated testing is necessary to ensure modifications to functionality don’t break other functions within the library. There is already some Automated Testing of the “snippets” repository with Github’s Travis server, but this has to be reconsidered and extended to cover the standalone packages too.
In order to be usable for a wider range of LilyPond users on a “consumer level” openLilyLib needs proper documentation. This documentation has to be generated from the sources, so a system is needed that requires package authors to document the input files and provide additional usage examples, from which documentation is generated. Ideally but not necessarily this is implemented as a Git hook, i.e. automatically upon each update to the repository. We don’t prescribe the tools and approaches to be used, but the most widely used language in the LilyPond domain is Python, so there would be some bias towards that. Alternatively a Scheme solution could be fine so generating the documentation would actually be triggered by “compiling” a certain LilyPond input file. In general it is advisable to make use of proven concepts and tools from other languages.
The eventual output of the documentation should be a static HTML site that can be viewed locally and/or uploaded to a website. But it would be beneficial if the tool would first generate an intermediate representation (e.g. a JSON file with additional media files) from which a Single Page Application could retrieve content for display on openLilyLib’s website. Development of such a SPA can be part of the GSoC project, but is optional.
Difficulty: medium
Requirements: Python or Scheme, static website generator(s) or (Node.js based) dynamic web application technology. Continuous Integration (can be learned during the bonding period)
Mentors: Urs Liska, Matteo Ceccarello
MusicXML
Improving MusicXML import and export functions:
File interchange between LilyPond and other applications using MusicXML
is still a difficult matter. To import MusicXML it has to be converted
manually by the musicxml2ly script. Export to MusicXML is
only available as a rudimentary feature inside Frescobaldi. In order to
provide natural interchange between LilyPond and MusicXML based
applications there’s the need of actual import functionality and a
dedicated export backend.
Importing XML shall provide file, line and column to add origin attributes to generated objects. That way point and click can be made available in Frescobaldi or other supported IDEs.
Exporting XML shall be realized with an exporter class like the MIDI export. This may be based on the work already done in GSoC 2015 by David Garfinkle. It should be checked if it is possible to use another XML library than the one provided by guile-2 in order to have this feature available in current LilyPond (which is based on guile-1.8).
Difficulty: medium
Requirements: MusicXML, Python, Scheme, basic LilyPond knowledge
Recommended: Familiarity with other scorewriters (for cross-testing)
Mentor: Jan-Peter Voigt
Information for Applicants/Participants
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 fulfil all of Google’s prerequisites and are willing to join the program as a full-time commitment over the coding period of three months.
- 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 students to make substantial efforts to become community members. Within the bonding period we expect you to write a blog post about your project (either on Scores of Beauty or on any other blog) and 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.
Autres langues : English, deutsch, español, italiano, 日本語, nederlands.
About automatic language selection.