X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fweb%2Fcommunity.itexi;h=5013b4d954681fdd5a44b45ee1e802450b6c4153;hb=7f4a65db65f3a8eba89cc9d78101f3f7fd71a5e9;hp=49103434fe063bac70b8c45d03e3938b0033bec1;hpb=5e7bd5c0a08893881d2c65d1440005455b43027f;p=lilypond.git diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi index 49103434fe..5013b4d954 100644 --- a/Documentation/web/community.itexi +++ b/Documentation/web/community.itexi @@ -178,8 +178,8 @@ be useful for others would better be posted to one of the mailing lists. @subsubheading Other languages @quotation -@uref{http://lists.gnu.org/mailman/listinfo/lilypond-es, -Spanish mailing list} +@uref{http://lists.gnu.org/mailman/listinfo/lilypond-user-fr, +French mailing list} @uref{http://www.lilypondforum.de/, German forum} @@ -187,26 +187,19 @@ German forum} @uref{http://groups.google.com/group/lilypond-brasil, Portuguese group} -@uref{http://lists.gnu.org/mailman/listinfo/lilypond-user-fr, -French mailing list} - -@uref{http://www.lilypondforum.nl/, -Dutch forum} +@uref{http://lists.gnu.org/mailman/listinfo/lilypond-es, +Spanish mailing list} @end quotation - @divEnd @divClass{column-right-top} -@subheading Stay Informed - -@subsubheading LilyPond Report +@subheading The LilyPond Blog -The easiest way to keep touch is by reading our community -newsletter, the LilyPond Report: +Read our community blog, @q{Scores of Beauty}: @example -@uref{http://news.lilynet.net} +@uref{http://lilypondblog.org} @end example @subsubheading Releases mailing list: @code{info-lilypond@@gnu.org} @@ -233,12 +226,12 @@ archive3} @divClass{column-right-bottom} -@subheading Developer Discussion +@subheading Developer Discussions and Translations @subsubheading Developer mailing list: @code{lilypond-devel@@gnu.org} -Most developer discussion takes place on this list. Patches -should be sent here. +Developer discussions take place on this list. Patches can also be sent +here. @quotation @uref{http://lists.gnu.org/mailman/listinfo/lilypond-devel, @@ -258,7 +251,8 @@ send to lilypond-devel with gmane} @subsubheading Bug mailing list: @code{bug-lilypond@@gnu.org} -Bug-specific discussion takes place here. +Bug reports and discussions should be sent here. Do not send patches +to this list. @quotation @uref{http://lists.gnu.org/mailman/listinfo/bug-lilypond, @@ -277,13 +271,16 @@ archive3} @warning{Before sending a message to the bug list, please read our guidelines for @ref{Bug reports}.} -@divEnd -@divClass{column-right-bottom} -@subheading Sensitive emails +@subsubheading Translation mailing list: @code{translations@@lilynet.org} -Private matters should be sent to Graham Percival (project -manager), who will discuss it with those concerned. +All discussions about translating LilyPond manuals should be sent here. +Do not send patches to this list. + +@quotation +@uref{http://lilypond-translations.3384276.n2.nabble.com/, +Translation mailing list archive} +@end quotation @divEnd @@ -415,7 +412,7 @@ then that is a bug. We may already know about this bug. Check here: @example -@uref{http://code.google.com/p/lilypond/issues/list} +@uref{http://sourceforge.net/p/testlilyissues/issues/} @end example @warning{Please @strong{DO NOT} add bug reports directly to the @@ -887,42 +884,195 @@ manuals can be found at @url{http://lilypond.org}} @divClass{column-center-top} @subheading What is Google Summer of Code? -A global program run by Google that offers students stipends for working -on open source software projects during summer vacations. +@uref{https://developers.google.com/open-source/gsoc/, GSoC} is a global +program that offers students stipends to write code for free software +and open source projects during the summer. It 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 @uref{http://www.gnu.org/, GNU project}. + +We have had GSoC participants in 2012 and 2015 and encourage students to +apply for future summers. -It is an excellent opportunity to find new contributors, and encourage -students already participating in LilyPond development, to become more -involved. One of our contributors was accepted in the 2012 program as -part of the @uref{http://www.gnu.org/, GNU project}; and we are always -looking for others to participate in future programs. +If you have questions or would like to apply, send us an email on our +developer mailing list (see @ref{Contact}). @divEnd -@divClass{column-center-bottom} -@subheading Our Ideas List +@divClass{column-center-middle-color2} +@subheading Project Ideas List + +Below is a list of suggested projects for GSoC or for anyone who is +interested in helping to improve LilyPond. (Last updated: February 2016) -Below is a list of projects that were suggested for the GSoC 2012 -students and is retained here as an inspiration for anyone -who is interested in developing LilyPond for future GSoC projects. +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. -There are many more things that can be done to improve LilyPond and -members of the LilyPond development team are always willing to help -those who would like to tackle projects such as those listed below. +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://code.google.com/p/lilypond/issues/list, here}. +@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://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. 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, 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{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 +@divClass{column-center-middle-color3} @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{Mentor(s):} 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 section 2.2 of +@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon,_Jean-Pierre%29, +this book}). 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 + +@divClass{column-center-middle-color3} @subheading MusicXML Improving MusicXML import and export functions: @@ -952,16 +1102,22 @@ 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{Mentor(s):} 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. +@divEnd +@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. @@ -969,53 +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{Mentor(s):} Mike Solomon - -@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(s):} Werner Lemberg - -@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{Mentor(s):} Mike Solomon, Carl Sorensen -@subheading Clean up various compilation warnings - -@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{Mentor(s):} Joe Neeman, Reinhold Kainhofer +@strong{Potential Mentors:} Mike Solomon, Janek Warchoł (both not available for +GSoC 2016) @divEnd