From obxwindsurf@yahoo.com Wed Oct 22 05:03:40 2003
Subject:Re: Update on Hammond Chorus/Vibrato simulator - launch has been scrubbed

I have already responded to Ron's CC, but I'll repost here with
embellishments and clarifications

Ron,

I've already designed the drawbar and switch
interface.

You don't need 18 inputs for 1 drawbar, you only need
8. One side of the drawbar gets common'ed (9
contacts), the pushed in position (all the way in) represents 0
input, and the remaining 8 are databus 0-7.

If you use the remaining (upper 8 bits) for I/O
control bus then you can scan up to 256 such groups of
8 data lines - more than enough.

A lot of external hardware is not needed in this case and there are
no RC time constants to deal with. All I'm interested in is "what
is the position of drawbar N?".

The lower 4 bits of the I/O control bus feed 2 4-line to 1:16
decoders with active low drivers. Data bus bits 0-7 are pulled hi
normally by pullup resistors. The common'ed side of the drawbar is
connected via a single 1n914B diode that when driven low puts an
active low through the drawbar and allows whichever drawbar position
to drive one of the D0-7 lines. At this point, all other drawbars
are floating and the only one we're interested in is the one we've
driven with a "drawbar enable" from the 1:16 decoder.

The 5th bit of the I/O control bus selects between the two decoders
with the first driving the swell drawbars, row of tablet switches,
and vibrato/chorus switch. The second drives the great drawbars and
the pedal drawbars. This allows me to optimize the code for
prioritizing one "bank" or the other if I so choose, although I
doubt that will be necessary. In effect I am only needing 1 wire
for a "select" for each drawbar rather than the 18 which Ron
suggested. Also there is only 1 wire for the select for the row of
tablet switches (only a single bit is needed to represent each of
their states), and 1 wire for the select of the V/C switch to
interrogate its position (6 bits).

Scanning latency and MIDI transmission I don't see as an issue -
with 10,000 instructions per second for the BS2sx

The biggest challenge is how much data you can persist
(The Basic Stamp only has 26 variables of 8 bits each). I'm making a
compromise - 24 drawbar positions stored and a bank of
7 switches for the tablet switches (1 bit each), and
another bank of 6 bits for vibrato/chorus settings (1 bit
each of 6 possible positions) - hence the 26 variables.

Although my controller will handle all the drawbars of the B4 I will
effectively "map" the missing drawbars of the M3 set in wiring -
another compromise given the limits of the M3 drawbars. However if
I acquire a full set of drawbars at a later date then my controller
will already accommodate them.

I'm not interested in mapping the analog pots of the B4 at this
point, opting to control those settings off of the "soft" panel on
the pc. Consequently, RC time constants and A/D conversion don't
come into the picture.

Since MIDI controller messages are modal and only need
to be sent when they change, you need to store the
current settings after scanning and initializing the
B4 from the controller settings upon power-up. After that you
simply compare the newly scanned setting, persist it & send the midi
controller message to the B4 if it has changed
since last scan. If there is no change in a drawbar or switch
setting, the MIDI spec has no need for resending a redundant message.

I've been an EE/Computer scientist for over 25 years
with half of that in hardware and analog/digital
instrumentation. The other half in computer science.

The Basic Stamp platform offers a lot of options (I'm
looking at the BS2sx which can execute 10K
instructions per second - more than enough for
scanning a few drawbars and switches.

There is more than one way to skin a cat. I've just chosen a
different approach than you have ;-)

I'll keep the group posted.

Regards,
Kevin

> reach across the pedal drawbar.
>
> Good Luck!
> Ron