Re: ideas for Google Summer of Code

[Graham Percival]

On Fri, Jan 16, 2009 at 12:36:12PM +0100, David Kastrup wrote:
> A rewrite of an intricate module intertwined with the bowels of lilypond
> is not something I consider realistic in this setting.  You need someone
> with good code knowledge to achieve that, and not just for mentoring.
> If the code is transparent enough that you can analyze and rewrite it in
> three months, it would likely have been done by old hands already if
> there is indeed a need.

On the contrary, if there's any feature which *cannot* be written
in three months, it will never be done.

Look at the bugs in the tracker.  At least 50% of them could be
fixed with 8 hours of Han-Wen's time.  (that's 8 hours per bug,
not 8 hours total, of course!)   He doesn't have the time to spend
8*(300/2) hours on these issues, though.


> Obviously, one wants something like that when converting tunes to
> tabulature.  In the course of that, one might also want to be able to
> insert algorithms for thinning out stuff: removing unplayable notes in
> clusters, substituting notes in a different octave, stuff like that,
> that is suitable for converting a "general music" score to the
> limitations of an actual instrument.  It has to be noted that this sort
> of "instrument physics" application is actually useful even if one
> renders to normal scores rather than tabulature.  It would also be nice
> to get fingering indications from a reasonably programmable strategy, so
> that one can have most of the fingerings of a fully spelled out finger
> exercise autogenerated, inserting only hints where things would
> otherwise go wrong.

Err... you're suggesting that lilypond should attempt to fix
orchestration mistakes by inexperienced composers?

That's not a terrible idea -- IIRC Sibelius and Finale already
have something like that built-in -- but it doesn't belong in the
main lilypond code.  I'd recommend writing a separate tool, using
python or something like htat.

Cheers,
- Graham