We have a nice Ideas List for Google Summer of Code. Now, each
project should have a mentor, who's job is to guide the student
working on the code and evaluate his/her work.
Mentors may or may not receive money, but they will surely win Eternal
Glory (and maybe a Graham's Kiss, who knows?). Please declare which
project(s) you are willing to mentor (remember that not all projects
will be launched):
1) Fixing problems with synchronization of grace notes, together with
all underlying architecture (issue 34). Grace notes are counfusing to
LilyPond's timing because they're like going back in time. This
causes weird effects, especially when one staff has a grace note and
the other don't.
Requirements: C++, MIDI; familiarity with LilyPond code and basic
music notation recommended.
2) Adding comprehensive MusicXML export and improving import, together
with tests checking how it works. Depending on time available,
implement some or all of the following:
-) Handle basic musical content export like the MIDI export (i.e.
using dedicated exporter classes, derived from the translator class)
-) Build the XML tree of the basic musical content, add a connection
from music event to XML tag
-) Let all LilyPond engravers do their job
-) add ability to link each output object (basically each stencil /
group of stencils) to the music cause (and thus to the XML tag in the
XML tree)
-) Add a XML output backend, which can then add the layout information
for each output object to the XML tags
The goal will be considered achieved when a (previously chosen) score
could be imported from MusicXML and exported back with no
unintentional loss of data.
Requirements: MusicXML, Python, basic LilyPond and music notation
knowledge; familiarity with other scorewriters would be a nice bonus
(for cross-testing).
3) Horizontal Spacing of Objects Attached to Notes: make spacing
depend on tightness of the music. The infrastructure should be
generic and extensible, so as to cover many types of grobs like
accidentals, dots, arpeggios etc.
Adding on-staff-line, between-staff-line, shorter and narrower
variants of some glyphs, for example accidentals, together with a
generic infrasctucture to support them. An example of notehead coming
in two variants is here
http://lilypond.googlecode.com/issues/attachment?aid=1839001name=hole+sizes+and+stem+thicknesses.pngtoken=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520inline=1
. Requirements: MetaFont, C++, good eye for details; basic LilyPond
knowledge recommended.
I (Janek) am willing to take this.
6) Improve default slur and tie curves - ties on enharmonic notes are
not supported { cis'~ des' }, ties broken by clef or staff change
aren't supprted well. Quite often LilyPond produces bad-looking slurs
and ties. Fixing this will require sorting examples of bad output and
generically deciding on intended output. Requirements: C++,
experience with writing heuristics; basic Scheme, music notation and
LilyPond knowledge recommended.
7) Improve default beaming. Better support for cross-staff, broken
and kneed beams; beaming should depend on context and neighbor notes
(see http://icking-music-archive.org/lists/sottisier/sottieng.pdf
section 2.2). Improve positioning of regular beams, possibly reducing
computation time. Requirements: C++, experience with writing
heuristics; basic music notation knowledge recommended.
8) clean up compiler warnings, static code analysis, and valgrind
warnings. Automatic code analysis tools (warnings in g++ and clang)
and analysis tools like valgrind memory leak detection and callgrind
code profilers provide valuable information about possible flaws in
C++ code. Cleaning these warnings would allow us to automatically
reject any patch which introduced extra warnings.
9) Rewrite font building system. Create a robust, scalable and easily
maintainable system for creating Open Type Fonts from Metafont code
(merging and dividing fontsets, handling different design sizes) using
Fontforge's built-in Python scripting support. Requirements: Python,
basic font and Metafont skills.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
