@include included/acknowledge.itexi
@include included/authors.itexi
+@include included/gsoc.itexi
@include included/helpus.itexi
@node Community
@ref{News}: news from the LilyPond project.
@item
-@ref{Attic}: announcements and changelogs from past versions.
+@ref{Attic}: announcements and changelogs from past versions,
+old news, etc.
@end itemize
@divEnd
@node Google Summer of Code
@unnumberedsec Google Summer of Code
-@divClass{column-center-top}
-@subheading What is Google Summer of Code?
-
-@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, 2015 and 2016 and encourage students
-to apply for future summers.
-
-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-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: November 2016)
-
-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 Adopt the SMuFL music font encoding standard
-
-For several years now a new standard for music fonts has been around:
-@uref{http://www.smufl.org/, 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.
-
-@strong{Difficulty:} Easy/medium
-@strong{Requirements:} C++ and willingness to get familiar with LilyPond
-internals.
-@strong{Recommended:} Interest and experience in working with font files.
-A little bit of METAFONT.
-@strong{Mentors:} Werner Lemberg, Abraham Lee
-
-@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
-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 (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%2C_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 Automated testing and documentation for openLilyLib
-
-@uref{https://github.com/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 @uref{https://openlilylib.org, website}. Development of
-such a SPA @emph{can} be part of the GSoC project, but is optional.
-
-@strong{Difficulty:} medium
-@strong{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)
-@strong{Mentors:} Urs Liska, Matteo Ceccarello
-
-@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:
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Handle basic musical content export like the MIDI export (i.e. using
-dedicated exporter classes, derived from the translator class).
-
-@item
-Build the XML tree of the basic musical content, add a connection from
-music event to XML tag.
-
-@item
-Let all LilyPond engravers do their job.
-
-@item
-Link each output object (i.e. each stencil or group of stencils) to the
-music cause (and thus to the XML tag in the XML tree).
-
-@item
-Add an XML output backend, which can then add layout information for
-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, 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 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 Mentors:} Mike Solomon, Janek Warchoł (both not available for
-GSoC 2016)
-
-@divEnd
+@gsocCurrent
@node Authors
@node News
@unnumberedsec News
-@divClass{heading-center}
-@warning{Many old announcements and changelogs can be found in
-the @ref{Attic}}
-@divEnd
-
-@include web/news-front.itexi
-
-@include web/news.itexi
+@include web/news-new.itexi
+@divClass{column-center-bottom}
+@subheading Old News
+Older news can be found in the @ref{Attic}, along with older
+announcements and changelogs
+@divEnd
@node Attic
@unnumberedsec Attic
@divEnd
-@divClass{column-center-bottom}
+@divClass{column-center-middle-color3}
@subheading Thanks
Thanks to developers, contributors, bug hunters and suggestions for
@divEnd
-@divClass{column-center-bottom}
+@divClass{column-center-middle-color3}
@subheading Changelogs
Developers' changelogs by version:
@miscLink{CHANGES-0.0,v0.0}
@divEnd
+
+@divClass{column-center-middle-color2 bigger-subsubheadings}
+@gsocInactive
+@divEnd
+
+@divClass{column-center-middle-color2}
+@subheading Old News
+
+Older news items dating back to July 2003. Newer news can be found on
+the @ref{News} page.
+@divEnd
+
+@include web/news-old.itexi
projects / lilypond.git / blobdiff