From 454b3fb7f54ccb196b58025e0308e727bc8ea7c3 Mon Sep 17 00:00:00 2001 From: Urs Liska Date: Mon, 15 Feb 2016 10:08:10 +0100 Subject: [PATCH] Issue 4763: Web: Review GSoC page Web/GSoC: Review list introduction Web/GSoC: Review ScholarLY project description Web/GSoC: Review Grace Notes project description Web/GSoC: Review MusicXML project description Web/GSoC: Review Slurs project description Web/GSoC: Review Glyphs project description Web/GSoC: Review Beaming project description Web/GSoC: Review Compilation project description Web/GSoC: Sort projects by mentor availability Web/GSoC: Insert Spanner-per-Voice project suggestion Web/GSoC: Incorporate suggestions by Paul's review Web/GSoC: Add "Chord structure" project --- Documentation/web/community.itexi | 216 +++++++++++++++++++----------- 1 file changed, 140 insertions(+), 76 deletions(-) diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi index a220917700..214ee64d40 100644 --- a/Documentation/web/community.itexi +++ b/Documentation/web/community.itexi @@ -904,44 +904,92 @@ developer mailing list (see @ref{Contact}). @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 @@ -949,13 +997,78 @@ edition and collaborative workflows. @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 @@ -989,9 +1102,13 @@ each output object to the XML tags. @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. @@ -1000,7 +1117,7 @@ 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. @@ -1008,61 +1125,8 @@ 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 -- 2.39.2