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

[address@hidden]

All of these look good.

On Feb 12, 2012, at 12:03 PM, Janek Warchoł wrote:

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

I have no clue how broken this is as the last time I used a grace note in a 
MIDI was 1998, but it seems like it's a reasonable thing to fix.

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

I worked on this a little bit - it is totally possible and would likely weigh 
in @ 500-1000 lines of Scheme.  I'd recommend not worrying about placement data 
and stopping at the engraver level.  This is more or less the same thing as a 
MIDI plus stuff like articulations, slurs, etc..  Placement data would be 
doable but hard: it'd be better to just get the info from engravers first.

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

This is a cool idea but wouldn't be a lot of work - in C++ it'd require 
20-50ish lines of code.

> 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(?).

This could be combined with the above to be a full project.

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

No clue how this stuff works, but sounds like a good idea.

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

This would take the entire summer if you added intelligent non-convex slurs.  
Here I could most certainly help out - it was on my summer-of-lily list but I'd 
gladly delegate to someone else!

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

Most beam problems that don't involve cross-staff or broken beams are fixable 
with 1-20 lines of code.  If you send me concrete examples, I can likely 
estimate how long it'd take.

Cheers,
MS