Re: ideas for Google Summer of Code

[David Kastrup]

Graham Percival <address@hidden> writes:

> A full list of possible projects is on the google issue list;
> there's something like 300 open issues.  Now, everybody has their
> pet projects, but IMO a SoC shouldn't be directed at
> instrument-specific tasks like accordian or gregorian notation.

I beg to differ.  See below.

> The two areas that most need in-depth, multiple-week attention:
> - rewrite of part combiner.
> - rewrite of grace notes.
> - ... I have the feeling there was one more item, but it escapes
>   me at the moment.

The problem here is we are looking at mentored tasks.  This implies that
the GSoC projects are directed at capable newcomers.  And they should be
finished in three months.

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.

Instrument-specific tasks, in contrast, have a reasonably limited scope
and reasonable requirements for complexity _unless_ we are talking about
notation that can't be put on paper with lilypond's current fundus of
constructs.

Personally, I think that instrument-specific tasks are quite well-suited
for GSoC projects, partly also because they might get filled in by
people well-acquainted with the instrument in question.

One thing I have been musing about is that maybe lilypond needs some
sort of instrument physics interfaces.

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.

Note that the task of designing such interfaces is not what I consider a
GSoC project.  But if such interfaces were available, filling them with
life for particular instruments would again be a ground for limited
separate projects fit for people well-acquainted with a particular
instrument and/or playing style.

-- 
David Kastrup