Re: Need interface/data structure design advice

[Carl Sorensen]

On 10/26/09 1:41 PM, "David Kastrup" <address@hidden> wrote:

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

I'd lean towards something like

bank-properties , an alist containing the properties of a bank:

((x-offset . bank-x-offset)
 (y-offset . bank-y-offset)
 (pitch-offset . bank-pitch-offset)
 (midi-intsrument . bank-midi-instrument))

By making it an alist, any of the properties can be left out and filled in
by default, and the order of the properties doesn't matter.  It's the way
most LilyPond properties are set.

Alternatively, bank-properties could be a list:

(bank-x-offset bank-y-offset bank-pitch-offset bank-midi-instrument)

This has less typing, but makes ordering important.  It also requires
non-standard accessor functions to get particular values, whereas the alist
can use standard LilyPond accessor functions (like chain-assoc-get).

The available banks would then be an alist of banks and bank-properties:
(define my-available-banks
'((bank1 . ((x-offset . x-offset1)
            (y-offset . y-offset1)
            (pitch-offset . pitch-offset1)
            (midi-instrument . midi-instrument1)))
  (bank2 . ((x-offset . x-offset2)
            (y-offset . y-offset2)
            (pitch-offset . pitch-offset2)
            (midi-instrument . midi-instrument2)))
  (bank3 . ((x-offset . x-offset3)
            (y-offset . y-offset3)
            (pitch-offset . pitch-offset3)
            (midi-instrument . midi-instrument3)))))

And it's really straightforward to add an additional bank.


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

Here I'd have a register that's a list of the banks that apply:

(bank1 bank3 bank7)

accordion-registers would then be an alist that contains all of the
available registers:

(define my-accordion-registers
'((register1 . (bank1 bank3 bank7))
  (register2 . (bank2))
  (register3 . (bank4 bank6))
  (register4 . (bank 5))))

Again, it's really straightforward to add an additional register.

An accordion could be defined as an alist containing available banks and
available registers:

(define my-accordion
  '((available-banks . my-available-banks)
    (available-registers . my-accordion-registers)))


One could either define a set of different accordions, each with the
appropriate banks and registers; or define a full set of accordion banks and
accordion registers that cover all possible accordions.

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

I'm not sure what this means, so I can't really comment on it.
> 
> 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.

I'm not clear what all this means.  I think there are two different issues
with actavation -- engraving and sound.  I think that LilyPond currently has
the functionality to get the engraving right, but will need some help with
the midi.  I can't provide any help at all with the midi; I have literally
never looked at the midi code (and have no plans to do so right now).  But I
would suggest that you separate these problems initially, and get the
engraving right first, then do the midi second.

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

I think the structure I have proposed is tweakable with standard LilyPond
\overrides.

HTH,

Carl