@divClass{column-center-middle-color2}
@subheading Project Ideas List
-Below is a list of projects that was initially drawn up for GSoC 2012.
-It is maintained here as inspiration for future GSoC projects and for
-anyone who is interested in developing LilyPond.
+Below is a list of suggested projects for GSoC or for anyone who is
+interested in helping to improve LilyPond. (Last updated: February 2016)
-Note that this is not an exhaustive list. Other GSoC projects are also
-possible. There are a number of areas where LilyPond could be improved
-and the LilyPond development team is always willing to help those who
-would like to tackle a project like those listed below.
+Mentor availability varies from project to project and from year to year.
+Send us an email on our developer mailing list (see @ref{Contact}), 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
@uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
@divEnd
+@divClass{column-center-middle-color3}
+@subheading 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.
+
+@strong{Difficulty:} Easy/medium
+@strong{Requirements:} Scheme (Guile), but the level necessary can be
+easily learned
+@strong{Recommended:} Chord theory and naming
+@strong{Mentor:} Carl Sorensen
+
+@divEnd
+
@divClass{column-center-middle-color3}
@subheading ScholarLY
ScholarLY is a library in
-@uref{https://github.com/openlilylib/snippets, 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.
+@uref{https://openlilylib.org, 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, for example: Inserting
+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
-@uref{https://github.com/openlilylib/scholarly/wiki/GSoC}.
+@uref{https://github.com/openlilylib/scholarly/wiki/GSoC, this Wiki page}.
@strong{Difficulty:} medium
@strong{Requirements:} Scheme, possibly LaTeX, (optionally Python)
@strong{Recommended:} Experience with or interest in scholarly
edition and collaborative workflows.
-@strong{Potential Mentor:} Urs Liska
+@strong{Mentor:} Urs Liska
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Adding variants of font glyphs
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Adding @q{on} and @q{between} staff-line variants.
+
+@item
+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 @q{hole} within
+it.
+
+@end itemize
+@divEnd
+
+@strong{Difficulty:} easy
+@strong{Requirements:} MetaFont, C++, good eye for details
+@strong{Recommended knowledge:} basic LilyPond knowledge
+@strong{Mentor:} Werner Lemberg
@divEnd
@subheading Grace notes
Fix problems with synchronization of grace notes. Grace notes can
-intefere with LilyPond's timing and cause odd effects, especially when
+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
+@uref{https://sourceforge.net/p/testlilyissues/issues/34/,bugs} in
+LilyPond.
@strong{Difficulty:} medium
@strong{Requirements:} C++, MIDI
@strong{Recommended:} familiarity with LilyPond internals
-@strong{Potential Mentors:} Mike Solomon, Carl Sorensen
+@strong{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
+Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading Improve default beam positioning
+
+For regular, cross-staff, broken and kneed beams. Beaming should depend
+on context and neighbor notes
+(see @uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf,
+section 2.2 here}). If possible also reduce beaming-computation time.
+
+@strong{Difficulty:} medium
+@strong{Requirements:} C++, experience with writing heuristics
+@strong{Recommended knowledge:} aesthetic sense
+@strong{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
+Carl Sorensen
+
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading 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
+
+@divClass{keep-bullets}
+@itemize
+
+@item specifying a “target context” where the end of the spanner is
+expected
+
+@item explicitly specifying the ending object with an ID
+
+@end itemize
+@divEnd
+
+This feature would solve many problems that are commonly faced with
+piano music and combined parts.
+
+@strong{Difficulty:} medium (?)
+@strong{Requirements:} C++, Scheme
+@strong{Potential Mentor:} Urs Liska
+@divEnd
+
+@divClass{column-center-middle-color3}
+@subheading 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.
+
+@strong{Difficulty:} medium
+@strong{Requirements:} C++
+@strong{Potential Mentors:} Reinhold Kainhofer (not available for GSoC
+2016), Joe Neeman
@divEnd
@end itemize
@divEnd
+There are several possibilities for this project, including building upon
+the MusicXML export project from GSoC 2015.
+
@strong{Difficulty:} medium
-@strong{Requirements:} MusicXML, Python, basic LilyPond knowledge
-@strong{Potential Mentors:} Reinhold Kainhofer, Mike Solomon
+@strong{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
+@strong{Potential Mentors:} Reinhold Kainhofer, Mike Solomon (both not
+available for GSoC 2016)
Familiarity with other scorewriters (for cross-testing) would also help.
@divClass{column-center-middle-color3}
@subheading Improve slurs and ties
-The default curves of slurs and ties are often unsatisfactory. Ties
+The engraving quality of slurs and ties is often unsatisfactory. Ties
@q{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.
@strong{Difficulty:} hard
@strong{Requirements:} C++, experience with writing heuristics
@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
-@strong{Potential Mentor:} Mike Solomon
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Adding variants of font glyphs
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Adding @q{on} and @q{between} staff-line variants.
-
-@item
-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 @q{hole} within
-it.
-
-@end itemize
-@divEnd
-
-@strong{Difficulty:} easy
-@strong{Requirements:} MetaFont, C++, good eye for details
-@strong{Recommended knowledge:} basic LilyPond knowledge
-@strong{Potential Mentor:} Werner Lemberg
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading Improve default beam positioning
-
-For regular, cross-staff, broken and kneed beams. Beaming should depend
-on context and neighbor notes
-(see @uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf,
-section 2.2 here}). If possible also reduce beaming-computation time.
-
-@strong{Difficulty:} medium
-@strong{Requirements:} C++, experience with writing heuristics
-@strong{Recommended knowledge:} aesthetic sense
-@strong{Potential Mentors:} Mike Solomon, Carl Sorensen
-
-@divEnd
-
-@divClass{column-center-middle-color3}
-@subheading 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.
-
-@strong{Difficulty:} medium
-@strong{Requirements:} C++
-@strong{Potential Mentors:} Joe Neeman, Reinhold Kainhofer
+@strong{Potential Mentors:} Mike Solomon, Janek Warchoł (both not available for
+GSoC 2016)
@divEnd
projects / lilypond.git / commitdiff