Issue 559: Feature request: support accordion with standard bass
http://code.google.com/p/lilypond/issues/detail?id=559
New issue report by v.villenave:
% This (very complete and documented) feature request was made
% by David Kastrup on the bug-list on Jan. 13th 2008, after
% a short discussion on -devel.
Accordion with standard bass is not well-supported in Lilypond.
There are diatonic (often bisonoric: with different tones on push and
pull) accordions which usually use special notations -- I am not
informed about those.
So I'll start with a short explanation of the chromatic accordion and
then explain the notations. We have two sides: discant and bass, and
they are pretty much written down in violin and bass clef, like with a
piano.
The discant side is rather unproblematic as it has one button or key per
note and uses standard notation. There are piano accordions with a
normal keyboard (they were invented for popularizing accordions by
providing a familiar interface), and button accordions with three rows
(if there are more, they are just replications for easier fingering) of
chromatically arranged buttons. C type (German, Finnish, Italian) and B
type (Russian) basically differ in the directions of the rows.
All of the discant details provide no complications for notation, with
the exception that a button accordion can offer about 5 octaves of
range, so the violin clef frequently gets octave shift modifiers. It is
common to write a "8" or "16" directly over a registration symbol to
indicate that a particular registration (Lilypond has these symbols
already apparently) is going to be played one or two octaves higher than
written.
But the bass is more problematic. The easiest case is when we are
talking about a score for "free bass" or "manual III": there one button
sounds one note, and the notation is straightforward, again in a
piano-like style.
Pure free bass accordions are quite rare. It is more common to have
"converter" accordions where either a manual II and manual III are right
behind each other (older Morino accordions do that), or where a special
mechanism can be used to switch from one type to the other. Some scores
require switching back and forth in mid-piece.
So what is this manual II (or standard or Stradella bass) system? It
offers buttons for bass notes and for chords (bass notes usually sound
stronger and/or deeper than the chord constituents). Physically there
are not more than 12 separate notes available for the bass notes and 12
for the chord constituents: a lever/gear system maps the buttons to
those. The most common kind has 6 rows of buttons, with 12 diagonals
each focused around a different tone, making for a total of 72 distinct
buttons. Whether one has 72, 96 or 120 basses makes no difference: the
additional diagonals are just repetitions for easier fingering.
The second row gives the fundamental bass notes (which are sorted C G D
A E ... from the marked middle). The first row just duplicates that,
but shifted by a major third (E B F# ... from the middle) to make stuff
easier fingerable.
The third to sixth rows give chords (again C G D ...), first the major,
then the minor, the major+seventh, and the diminuished chord (which is
actually not complete, since it is missing the diminuished fifth). Some
accordion pages (like Wikipedia) claim that the seventh chord is also
missing the fifth, and I find this reflected in the notation of pieces.
Unfortunately, both my accordions tend to differ.
Ok, what does this imply for Lilypond? Basically, we have three areas
that are concerned: entry, layout, midi.
Entry: since bass note and chord constituents may sound differently,
they must always be distinguishable.
Now Lilypond already has a chord concept, and figuring out an accordion
bass from a non-accordion specific input is probably fine as long as one
can figure out the bass note. With an accordion, chord inversions don't
actually count. So the algorithm probably would work by subtracting the
bass note from the sounded notes, then taking the chord that matches the
largest number of the remaining notes (ignoring the octave and not
sounding any note not in the original chord). A diminuished chord
should probably (optionally?) also remove its non-existent fifth (while
not using it for matching purposes). It should be configurable whether
a seventh chord must have a match for its straight fifth or not as this
is obviously dependent on the instrument. Similarly, it should be
possible for accordions with a different row layout to get matched to
existing music. When no more chord fits, the rest may possibly filled
in with bass notes or left alone.
An algorithm like that would probably be able to synthesize most Jazz
harmonies.
I think that the existing chord/bass note system should mostly be
tolerable for entry here, except that for the accordion, chords may get
sounded without a bass note, and bass notes without a chord.
One notable information that is often present is whether a bass note is
to be played on the second (main) row, or on the first row (the bass row
containing thirds). Sort of fingering information, but pretty much
always specified.
Anyway, let us come to the output. Here is where things are getting
really messy.
With the score, we have basically two flavors: German and American
Accordion Association. The main difference is that in the German
notation chords are written out, whereas AAA notation is quite closer to
numbered bass notation in that a chord is written as its principal base
note (discounting inversions!) with possibly a letter above (like an
accidental, the letters tend not to get repeated). Letters are M for
major (the default, so only needed for dissolving a previously given
different letter), m for minor, 7 for seventh and d for diminuished. So
the AAA notation is less cluttered (with fewer noteheads), but harder to
transfer to other instruments. The principal bass note is put below the
middle line from the bass clef (C position and lower), the chords on the
middle line and above. This division is hard in order to make the
notation unique: when transposing, one needs to wrap around the octaves.
Now we come to the really fuzzy notation, the German one. Here the
chords are written out in notes, and usually also with chord/bass names
below the staff. The principal bass/chord division is the same, and
chords are written out in the lowest place where they fit disregarding
chord inversions. That is sort of a canonical notation. The fuzz comes
into play since writing out the chords makes it possible to play it on
other instruments, most notably a free bass accordion. And then chord
inversions do matter. Since chords and bass notes are distinguishable
by the number of stacked notes, their division tends to be weakened:
bass lines will at times not be wrapped around, and chords may reach
below the middle line when the equivalent free bass would finger them
there.
Whether one wants to have bass notes wrap around or chords to change to
a different inversion when transposing is certainly user/writer choice.
Also the writer needs to have a way to say "don't move my bass
notes/chords to different places" while the default would likely
normalize both chords and basses.
Now to the Midi output: to make things even more annoying, the bass
system has just 12 notes, as told. But where the wraparound in the
notation occurs at C, the wraparound in the most common instrument type
occurs at E (that is, E is the lowest note, Eb the highest). I think
that some instruments might wrap around somewhere else, but...
So if we want to cater for life-realistic Midi, we might need to wrap
around against some other thresholds with regard to chords/inversions
than we do in the notation.
I won't vouch for all of the details, but that is the gist. Note that
one can produce something like that with lilypond visually, but
a) one has to code the chords manually which means that it is not
trivial to produce output for, say, accordeon and piano and figured bass
from the same input.
b) chords and bass notes don't stay in their designated space when
transposed.
c) when chords are not written out, the midi output will not correspond
with the actual sound.
Any thoughts how much work would be involved in tackling any of those
three problems, and what mechanisms that are already in place could be
get used favorably? I would be willing considering to sponsor some
development here but one should flesh out what is sensible here in
advance, and how much work would need to get put in what area.
Issue attributes:
Status: Accepted
Owner: v.villenave
Labels: Type-Enhancement Priority-Postponed Bounty
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
