Re: Google Summer of Code - Ideas List, please discuss

[Graham Percival]

On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
> 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.

umm, you know that we already have musicxml2ly import, right?

I agree with having this on the ideas list, but it should
definitely mention musicxml2ly.py and basic familiarity with
python.  The export would most likely be in scheme, although it's
not impossible to imagine that somebody might write a relatively
simple scheme exporter to an intermediate format (or just use
\displaymusic{} ), then use python to construct the actual
musicxml file.

> 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.

I think this item needs rewriting.  If Phil and Julien want to
highlight exactly what is left, great; otherwise I'd be tempted to
leave it out.

Then again, it's just possible that Phil or Julien might be
interested in being student in GSoC, in which case we should
definitely include this as a project.

> 6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking

Don't call it "Grand".  It would be a big chunk of work, sure, but
don't underestimate how much can be done in full-time work.




I'd add another item to the list:
n+1) 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.  It would be great if somebody could
clean up those warnings, as this would allow us to automatically
reject any patch which introduced extra warnings.  Once compiler
warnings are fixed, analysis of memory leaks and profiling would
be great.

- Graham