Need interface/data structure design advice

[David Kastrup]

Hi,

I am working on accordion register symbol typesetting right now.  Up to
now, there are some font elements in the font, and some basic hackish
stuff in the snippets.

Right now I am stuck in the interfaces.  The focus right now is discant
registers, other registers have similar concerns.

Now here is the basic data I have to deal with:

The register symbols have a basic symbol, and they have dots that are on
or off.

(cf <URL:http://en.wikipedia.org/wiki/Accordion_reed_ranks_&_switches>)

The German page
<URL:http://de.wikipedia.org/wiki/Register_(Akkordeon)> has quite a few
more details with regard to naming schemes.

The dots correspond to reed banks.  For some accordions, there are
unusual reed banks (and dots), so the user should be able to add dot
coordinates and corresponding data.

For each dot, there will be a set of coordinates where to draw it on the
accordion symbol, a default midi instrument and a default pitch
adjustment: accordions have reed banks that are one octave off, but they
also have reed banks that are only a few cents off-pitch, usually with a
linear tuning curve (linear in cents/semitone, with the lower notes
being more cents off and the higher less).

So we want a default midi instrument per reed bank, with an optional
fine-tuning (translated in pitch bend).

Now to registers: a register is a combination of reed banks (and dots on
the symbol).  A register has a name.  I don't think that cleverness is
warranted for pulling apart register names like "101" or "MM" or
whatever else: the combinations are few enough that it is fine not to
pick apart those strings but just use them as identifier for one
register each.

Registers should have an override regarding the used midi instruments in
order to adapt them to available patches.

Now there is an additional complication: if the lowest used reed bank is
not at nominal pitch (namely either 16" or 4"), notation and sound are
not in accord.  It is common to write at pitch and affix an "8" or more
wordy equivalent at the top or bottom (depending on whether to play one
octave lower or higher than written) of the register symbol to indicate
that one should play one octave higher/lower in order to get pitch.  If
this octavation (in playing) is dissolved, there is "loco" at the next
register symbol.

So usually the register symbol should interact in some manner with
\ottava specs.  Accordions are usually limited enough in range not to
need ottava notation in addition to registration: the keyboard for piano
accordions tends to go from f to a''', really big ones e to c''''.
Chromatic button accordions are a bit more impressive, mine has notes
from a, to bes'''', so some possible use for ottava changes that are not
directly related to register changes is there: those would likely use
ottava brackets independent of the current register.

It is common to have different registers for different repeats and write
that out.  That would be nice to have in Midi.  However, it is also
common to have different dynamics for different repeats, and Lilypond
has no way to deal with that right now IIRC.  So that's a different
topic and should likely be addressed in the context of repeats without
special consideration of accordions.

Ok, all this verbage: there need to be ways to specify the available
reed banks, their dot layout, their midi impact and audible octave.
Registers have a reed bank combination and a sounding octave of the
lowest reed bank, and should have an override for the chosen midi
output.

This situation is principally the same in bass registrations for free
bass, and with some modifications for standard bass
(cf. <URL:http://www.accordions.com/index/art/stradella.shtml>) where
some reed banks are used for chords, and some for single bass notes
(usually sounding the chord banks as well through mechanical couplers).

So the same mechanisms for tweaking, dot layout specification, register
naming, midi impact, and use should apply.

What kind of data structure can I use such that one can tweak with a
reasonable interface?

-- 
David Kastrup