Re: ideas for Google Summer of Code

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Fri, Jan 16, 2009 at 12:36:12PM +0100, David Kastrup wrote:
>
>> 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?

Yup, like Bach who did a lousy job writing for accordion or guitar.  An
astonishing lack of insight considering that he had the balls to write
the B minor mass (not performable at his life time: the first full
performance was after he had been considerably longer dead than alive
already).

More seriously: orchestration is work.  If lilypond makes it easier for
the composer to do this sort of work, so much the better.

The accordion is one example of an instrument for which orchestration is
a complete nuisance: available range (both absolute and relative: with
button accordions you can easily span a two-octave interval with the
right hand, which you could not hope to do with piano accordions) and
free bass and registration differ wildly from specimen to specimen.  So
composers partly have to err on the safe side (or not) and pretty much
every player has to either lug around universal playing machines
weighing something like 35lb, or arrange their own stuff.  There is also
the question about what notes are in a chord.  Most accordions nowadays
omit the fifths from seventh and diminuished chord buttons.  The French
system has only one button for _both_ chord types, and it serves as a
seventh chord (for the subdominant) _including_ the fifth, but omitting
the tonic.  So G-Bb-E is used for G0 as well as C7 on those instruments,
whereas on the 6-row chord systems, C7 has its own button carrying
C-E-Bb.  Unless you have an older German instrument (the older high end
Morinos from Hohner counting as Italian) which has the full C-E-G-Bb.
But if one wants to convert a leadsheet to accordion, one will use the
fifth-less chords available on the instrument usually.

So in short: you can't reasonably compose for "accordion" in general,
but rather are composing for a particular specimen.  Similar things are
going on with other instruments (flute, fagott, saxophone) where the
range is sometimes mechanically extended with additional notes.  The
reason obviously is not to compensate for inexperienced composers, but
to be able to use the musical material more flexibly, adapting it to the
available instruments.

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

It could be argued that some sort of Prolog-like system of specifying
limitations might be more natural.  Or a TeX-like system of specifying
penalties for certain transitions and mappings, and let the system then
find the shortest matching graph across (with hard-specified fingerings
serving as hard constraints, obviously).

It appears obvious to me that instrumental experts will not commonly be
able to write algorithms (let alone efficient ones), but will be able to
contribute tweaks to settings.

For typesetting tasks, efficient shortest graph traversal based on
penalties seems to be a nice component to work with (TeX's linebreak
decisions are done in such a way, and the results are pretty solid).

-- 
David Kastrup