1 @c -*- coding: utf-8; mode: texinfo; -*-
2 @c This file is part of community.itexi
3 @c It's been moved here to reduce maintenance burden on translators. It's up
4 @c to translators the choice of translating this section of community.itexi or
5 @c not (as GSoC students are required to speak english, a translated page is
8 @c Current proposals for Google Summer of Code
11 @divClass{column-center-top}
12 @subheading What is Google Summer of Code?
14 @uref{https://summerofcode.withgoogle.com/, GSoC} is a global program
15 that offers students stipends to write code for free software and open
16 source projects during the summer. For three months students work to
17 complete a given task as part of the project's community and under the
18 guidance of experienced mentors. The program is an excellent
19 opportunity for students to gain experience with real-world software
20 development and make a contribution that benefits everyone. It brings
21 new contributors to LilyPond and enables students who are already
22 involved to become more involved. LilyPond participates in GSoC as part
23 of the @uref{http://www.gnu.org/, GNU project}.
25 We have had GSoC participants in 2012, 2015, 2016 and 2017. This site
26 will be updated in time before the 2018 season will start.
30 @divClass{column-center-middle-color2 bigger-subsubheadings}
31 @subheading Project Ideas List
33 Below is a list of GSoC project ideas (last update: May 2017), but
34 if you have other ideas for a project you may complete within the three
35 months of the program you're welcome to make a suggestion on our
36 developer mailing list (see @ref{Contact}). There are a number of areas
37 where LilyPond could be improved, and our development team is always
38 willing to help those who would like to tackle a project similar to
39 those listed below. As mentor availability varies from project to
40 project and from year to year it is wise to get in touch with us as
43 A full list of all the current open issues can be found
44 @uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
47 @subsubheading Adopt the SMuFL music font encoding standard
49 For several years now a new standard for music fonts has been around:
50 @uref{http://www.smufl.org/, SMuFL}, which is also discussed as becoming part of
51 a future W3C standard for music encoding. As a FLOSS tool LilyPond should
52 adhere to such an open standard instead of using an isolated solution like it
53 does today. Adopting SMuFL will help integrating LilyPond with the world of
54 music notation software and eventually give LilyPond users access to a wider
55 selection of notation fonts.
57 Making LilyPond compliant to SMuFL includes remapping of the glyphs that are
58 built from METAFONT sources, adjusting the glyphs' metrics to SMuFL's
59 specifications, and finally updating the way LilyPond looks up and positions the
60 glyphs. As an optional part of this project LilyPond's font loading mechanism
61 could be modified to use notation fonts installed as system fonts instead of
62 inside the LilyPond installation.
64 @emph{Difficulty}: Easy/medium
66 @emph{Requirements}: C++ and willingness to get familiar with LilyPond
69 @emph{Recommended}: Interest and experience in working with font files.
70 A little bit of METAFONT.
72 @emph{Mentors}: Werner Lemberg, Abraham Lee
75 @subsubheading Adding variants of font glyphs
77 @divClass{keep-bullets}
81 Adding @q{on} and @q{between} staff-line variants.
84 Shorter and narrower variants of some glyphs for example, accidentals.
85 Another, more specific example could be an ancient notation breve
86 notehead coming in two variants one with a small or big @q{hole} within
92 @emph{Difficulty:} easy
94 @emph{Requirements:} MetaFont, C++, good eye for details
96 @emph{Recommended knowledge:} basic LilyPond knowledge
98 @emph{Mentor:} Werner Lemberg
101 @subsubheading Contemporary Notation
103 LilyPond is very good at creating non-standard notation. Having to
104 @emph{code} every graphical element instead of simply @emph{drawing}
105 it may seem cumbersome but is in fact a strong asset. New notational
106 functionality can be provided with consistent appearance, automatic
107 layout and a natural syntactic interface.
109 Within the @uref{https://github.com/openlilylib/oll-core, openLilyLib}
110 library system the student will create a fundamental infrastructure
111 and building blocks to make creating contemporary notation easier.
112 Additionally (at least) @emph{one} concrete package is developed to
113 cover specific contemporary notation, such as for example the style
114 of a given composer, extended playing techniques for a specific
115 instrument or a certain category of effects.
117 @emph{Difficulty:} medium
119 @emph{Requirements:} Scheme (interaction with LilyPond internals),
120 contemporary notation techniques
122 @emph{Recommended:} sense of building hierarchical frameworks
124 @emph{Mentors:} @emph{NN,} Urs Liska
127 @subsubheading Rewrite LibreOffice LilyPond Extension with Python
129 The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension
130 made it possible to conveniently include LilyPond score snippets in
131 OpenOffice.org/LibreOffice Writer, Draw and Impress documents while
132 keeping source and image together. After many years without development
133 an initial effort has started to make the extension compatible again
134 with current versions of LibreOffice and LilyPond.
136 However, as the LibreOffice ecosystem has changed substantially it is
137 now possible to rewrite the extension with Python and PyQt. This will
138 not only be more powerful in general but will allow the integration of
139 functionality from @uref{http://frescobaldi.org, Frescobaldi}, such as
140 for example syntax highlighting, entry helpers, score wizards or musical
143 @emph{Difficulty:} easy/medium
145 @emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice
148 @emph{Recommended knowledge:} Familiarity with Frescobaldi code based
149 or willingness to learn during bonding period
151 @emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
154 @subsubheading Automated testing and documentation for openLilyLib
156 @uref{https://github.com/openlilylib, openLilyLib} is an extension
157 framework for LilyPond code providing a “snippets” repository and a
158 suite of integrated packages such as for example page layout tools or
159 scholarly annotations. It is very powerful and promising, but to really
160 get off the ground two features are missing: automated testing and
161 documentation generation.
163 Automated testing is necessary to ensure modifications to functionality
164 don't break other functions within the library. There is already some
165 Automated Testing of the “snippets” repository with Github's Travis
166 server, but this has to be reconsidered and extended to cover the
167 standalone packages too.
169 In order to be usable for a wider range of LilyPond users on a “consumer
170 level” openLilyLib needs proper documentation. This documentation has
171 to be generated from the sources, so a system is needed that requires
172 package authors to document the input files and provide additional usage
173 examples, from which documentation is generated. Ideally but not
174 necessarily this is implemented as a Git hook, i.e. automatically upon
175 each update to the repository. We don't prescribe the tools and
176 approaches to be used, but the most widely used language in the LilyPond
177 domain is Python, so there would be some bias towards that.
178 Alternatively a Scheme solution could be fine so generating the
179 documentation would actually be triggered by “compiling” a certain
180 LilyPond input file. In general it is advisable to make use of proven
181 concepts and tools from other languages.
183 The eventual output of the documentation should be a static HTML site
184 that can be viewed locally and/or uploaded to a website. But it would
185 be beneficial if the tool would first generate an intermediate
186 representation (e.g. a JSON file with additional media files) from which
187 a Single Page Application could retrieve content for display on
188 openLilyLib's @uref{https://openlilylib.org, website}. Development of
189 such a SPA @emph{can} be part of the GSoC project, but is optional.
191 @emph{Difficulty:} medium
193 @emph{Requirements:} Python or Scheme, static website generator(s) or
194 (Node.js based) dynamic web application technology. Continuous
195 Integration (can be learned during the bonding period)
197 @emph{Mentors:} Urs Liska, Matteo Ceccarello
200 @subsubheading MusicXML
202 Improving MusicXML import and export functions:
204 File interchange between LilyPond and other applications using MusicXML
205 is still a difficult matter. To import MusicXML it has to be converted
206 manually by the @code{musicxml2ly} script. Export @emph{to} MusicXML is
207 only available as a rudimentary feature inside Frescobaldi. In order to
208 provide natural interchange between LilyPond and MusicXML based
209 applications there's the need of actual import functionality and a
210 dedicated export backend.
212 Importing XML shall provide file, line and column to add origin
213 attributes to generated objects. That way point and click can be
214 made available in Frescobaldi or other supported IDEs.
216 Exporting XML shall be realized with an exporter class like the MIDI
217 export. This may be based on the work already done in
218 @uref{https://github.com/DavidGarfinkle/Lilypond_MusicXMLexport, GSoC 2015}
219 by David Garfinkle. It should be checked if it is possible to use
220 another XML library than the one provided by guile-2 in order to have
221 this feature available in current LilyPond (which is based on guile-1.8).
223 @emph{Difficulty:} medium
225 @emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
227 @emph{Recommended:} Familiarity with other scorewriters (for cross-testing)
229 @emph{Mentor:} Jan-Peter Voigt
234 @divClass{column-center-middle-color2}
235 @subheading Information for Applicants/Participants
237 In order to have a satisfying experience with GSoC applicants are
238 strongly advised to thoroughly read the following recommendations. Some
239 of these are relevant for the application process, others for the time
245 Read all applicable information on the program's website, particularly
247 @uref{https://developers.google.com/open-source/gsoc/resources/manual,
248 students' manual}. Make sure you fulfil all of Google's prerequisites
249 and are willing to join the program as a full-time commitment over the
250 coding period of three months.
253 Please get in touch with us as soon as possible if you are interested in
254 applying with a project. Mentor availability may change without notice,
255 project proposals may need fine-tuning, and many other reasons might
256 require us to reject or ignore an application that hasn't been discussed
260 We do not know in advance how many “slots” we will have available for
261 projects, so please be aware that you may find yourself in competition
262 with other applicants or not. Interested or even enthusiastic response
263 from our mentors is no guarantee of eventually being accepted, and
264 @emph{not} being accepted does not necessarily indicate a negative
265 evaluation of your application. If we have to decide between different
266 applicants there may be various aspects to consider.
269 Integration in the LilyPond community is a fundamental part of GSoC, and
270 we expect our students to make substantial efforts to become community
271 members. Within the @emph{bonding period} we expect you to write a blog
272 post about your project (either on @uref{http://lilypondblog.org, Scores
273 of Beauty} or on any other blog) and to be active on our mailing lists,
274 introducing yourself but also communicating about unrelated tasks. This
275 goes beyond the mere setting up of a working environment and
276 familiarizing yourself with the relevant code, but we think it is
277 crucial for the GSoC project to be mutually satisfying.
280 If you are accepted to the program you will have one mentor explicitly
281 assigned to your project. With this mentor you will have to agree upon
282 a communication strategy, be it emails, chatrooms, issue trackers or
283 voice/video chats. Regular communication is absolutely crucial for the
284 success of a GSoC project so you are stricly required to keep talking to
285 your mentor. But keep in mind that your mentor has explicitly taken
286 over the responsibility for your project, and while unlike you he isn't
287 paid for this activity you are still entitled to get regular attention
291 In order to get support from your mentor you have to give him a chance
292 to follow your progress and efforts. Therefore it is important to
293 regularly commit your changes to the versioning repository you are
294 working on. Don't hesitate making unfinished code available because you
295 are afraid of criticism, and don't suppress questions because you think
296 they might be considered stupid. But ideally your code should at any
297 time be accompanied by compatible testing code. Your mentor may not be
298 able to properly assess your code by only @emph{reading} it without the
299 opportunity to apply it in a real example.
303 There is a list of inactive projects in the @ref{Attic}. We list
304 projects there that are still considered valuable but for which there
305 are currently no mentors available.
311 @c Inactive proposals for Google Summer of Code
313 @subheading Inactive Google Summer of Code project suggestions
315 The following list describes GSoC projects that had been proposed
316 in recent years and which are still considered valuable but for
317 which we currently don't have mentors available.
320 @subsubheading Improve slurs and ties
322 The engraving quality of slurs and ties is often unsatisfactory. Ties
323 @q{broken} by clef or staff changes are not handled well. The project
324 could include collecting and sorting examples of bad output, deciding on
325 the intended output and writing code to improve them.
327 @emph{Difficulty:} hard
329 @emph{Requirements:} C++, experience with writing heuristics
331 @emph{Recommended knowledge:} LilyPond knowledge, aesthetic sense
334 @subsubheading Grace notes
336 Fix problems with synchronization of grace notes. Grace notes can
337 interfere with LilyPond's timing and cause odd effects, especially when
338 multiple staffs are used where some have grace notes and others don't.
339 This is one of the longest-standing and one of the more embarrassing
340 @uref{https://sourceforge.net/p/testlilyissues/issues/34/,bugs} in
343 @emph{Difficulty:} medium
345 @emph{Requirements:} C++, MIDI
347 @emph{Recommended:} familiarity with LilyPond internals
350 @subsubheading Improve default beam positioning
352 For regular, cross-staff, broken and kneed beams. Beaming should depend
353 on context and neighbor notes (see section 2.2 of
354 @uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon%2C_Jean-Pierre%29,
355 this book}). If possible also reduce beaming-computation time.
357 @emph{Difficulty:} medium
359 @emph{Requirements:} C++, experience with writing heuristics
361 @emph{Recommended knowledge:} aesthetic sense
364 @subsubheading Help improve compilation behavior
366 Automatic code analysis tools, like valgrind memory leak detection or
367 callgrind code profilers, provide valuable information about possible
368 flaws in our C++ code. Cleaning up warnings would allow us to automate
369 the rejection of any patch which introduced extra warnings.
371 @emph{Difficulty:} medium
373 @emph{Requirements:} C++