Google Summer of Code - Ideas List, please discuss

[Janek Warchoł]

Hi all,

SUMMARY: in order to participate in Google Summer of Code ($$$), we
need an Ideas List.

(to learn more about GSoC, go here
http://www.google-melange.com/gsoc/homepage/google/gsoc2012)

An Ideas List should be a list of suggested student projects.  This
list is meant to introduce contributors to the project's needs and to
provide inspiration to would-be student applicants.

For an example, go here:
http://community.kde.org/GSoC/2011/Ideas#Project:_KStars:_Improve_the_observation_planner_and_logging_feature

Below are my suggestions for our Ideas List.  Please comment on them
and give your suggested projects.



General student prerequisites: (basic?) git knowledge

1) Fixing problems with synchronization of grace notes, together with
all underlying architecture (issue 34). Requirements: C++, MIDI;
familiarity with basic music notation recommended

2) Adding comprehensive MusicXML import and export features, together
with test suites for it.  Requirements: ? (no idea in which language
this would be written), MusicXML, basic LilyPond and music notation
knowledge; familiarity with other scorewriters would be a nice bonus
(for cross-testing).  The goal would be considered achieved when a
(previously chosen) not-so-complicated score could be imported from
MusicXML and exported back with no (unintentional) loss of data.

3) Horizontal Spacing of Objects Attached to Notes, esp. Accidentals:
make spacing depend on tightness of the music.  This is thoroughly
explained in issues 2141, 2142, 2143 ans 2144.  Also, the
infrastructure needed to solve 2142 should be generic and extensible,
so as to cover other types of grobs like dots, arpeggios etc (see
comment 8 on issue 2142 -
http://code.google.com/p/lilypond/issues/detail?id=2142#c8).
Requirements:

4) Currently some glyphs come in two varieties: for use on staff lines
and between them (an example of noteheads with varying hole size is
here 
http://lilypond.googlecode.com/issues/attachment?aid=18390010000&name=hole+sizes+and+stem+thicknesses.png&token=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520&inline=1).
 It would be nice to add such variants to other glyphs, for example
accidentals and flags, together with a generic infrasctucture to
support them.  Also, narrower and shorter variants of some glyphs
would be handy, see
http://code.google.com/p/lilypond/issues/detail?id=2145 and
http://code.google.com/p/lilypond/issues/detail?id=2203. Requirements:
MetaFont, C++(?), good eye for details; basic LilyPond knowledge
recommended(?).

5) Build System Improvement: if we want to ever move away from make,
this would be a good opportunity.  Issues like thousands of errors and
warnings during compilation should be removed, all dependancies fixed
(so that one doesn't need to remove fonts folder to have fonts
rebuilt).  Requirements: Python, Make and (optionally) another build
system.

6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking
slurs and ties, ties on enharmonic notes are not supported { cis'~
des' }, ties "broken" by clef or staff change aren't supprted well,
etc. (as for bad shapes, i have a big report on ties halfway done, and
slur examples would need to be collected from mutopia or from users).
Requirements: C++, experience with writing heuristics; basic Scheme,
music notation and LilyPond knowledge recommended.  This project seems
really big to me, unless all of the research and testing would be done
by someone else (bad idea).

7) Grand Beam Project - there are cases of badly-looking beaming, even
in very simple snippets (again, i have a huge report on this matter
halfway-done). Also, beaming should depend on context and neighbor
notes (see http://icking-music-archive.org/lists/sottisier/sottieng.pdf
section 2.2, i can also give some more examples).  Changing beam code
to do this looks like a fairly complicated matter. Requirements: C++,
experience with writing heuristics; basic music notation knowledge
recommended.

I have two more Grand Projects, but they are totally undocumented now.

cheers,
Janek