keyboard modifications

[harry]

Hi Gene (et al)

I use a dual bus keyboard, which takes care of the latch problem. Other than
that
you have to use a one-shot to delay the latch strobe until you have valid
data... and
that takes time. But for someone like me, a couple of milliseconds isn't a
problem.

My biggest problem in N-key rollover. In this case I might hit two adjacent
keys and have a race condition... So low note priority works best for a sloppy
player like me.

I don't know of an integral latch circuit... anyone  ????

H^) harry

Debby and Gene Stopp wrote:

> I've used rubber-button keyboards for monophonic CV-output keyboards, with
> excellent results. I use scanning interfaces myself - ever since I built the
> one out of Electronotes back in the 70's, I've never gone back. I've even
> added one to my Minimoog so it always plays correctly.
>
> I don't have experience with the priority encoder approach, but sometimes I
> think about trying it. I did make a programmer for another Minimoog with a
> priority encoder, and I had some problems latching the word output reliably.
> Fortunately there's a technique that I can use to get a good latch - push
> the button firmly and hold it for a second. On a keyboard it might be an
> issue however.
>
> One of my scanning interfaces uses a single chip! I programmed the circuit
> into an Altera part once.
>
> The advantages of digitizing a keyboard versus using a resistor string are
> numerous. The DAC never drifts over time, unlike an analog S/H. This means
> you can leave the keyboard connected while you control the synth externally,
> like in MIDI-CV setups. The scanning circuitry never makes a mistake - with
> an analog S/H you will probably get the occasional dropped note. Also with a
> scanning circuit you can do neat tricks like switchable hi-note or low-note
> priority, by making the scan counter up count or down count. One thing I've
> never tried is triggering the DAC latch with an LFO, which would
> theoretically provide a random voltage output that is already quantized.
>
> Is there a cascadeable priority encoder with a latched output? That would
> make for a real simple keyboard circuit. I've only used the TTL version,
> which needs an external latch.
>
> - Gene
>
> ----- Original Message -----
> From: "harry" <harrybissell at prodigy.net>
> To: <WeAreAs1 at aol.com>
> Cc: <mysynth at hotmail.com>; <synth-diy at node12b53.a2000.nl>
> Sent: Monday, December 11, 2000 5:35 PM
> Subject: Re: keyboard modifications
>
> > Hello Michael (et al)
> >
> > Correct... the EFM style needs a low contact resistance. You could
> possibly
> > trigger
> > a good analog switch... but the DAC is the best way to go.  If you don't
> want to
> > have the keyboard scan, try the 4532 8 input priority encoder. Very easy
> to
> > generate
> > a word with... uhh... priority ???
> >
> > H^) harry
> >
> > WeAreAs1 at aol.com wrote:
> >
> > > In a message dated 12/11/00 4:29:03 PM, mysynth at hotmail.com writes:
> > >
> > > << What kind of keyboards are people modifying for DIY use?
> > >
> > > I have three different old keyboards here... one Sequential Circuits
> > > Six-Track and two Casios.  I disassembled them with an eye towards
> > > cannibalization and found identical rubber-bubble type contacts.
> > >
> > > On exploring further, I tried to ohm-out the switches on the keys and
> found
> > > a fairly consistant 150 to 200 ohms is the best I could do.  Is this
> typical
> > > for this style switch?  My guess is this resistance would reign havoc
> with
> > > the EFM keyboard controllers (asking as they do for 100 ohm @ 1%
> tolorance).
> > > >>
> > >
> > > If you wish to use this type of rubber-contact keyboard for generating
> > > control voltage, the best way would probably be to connect the keyboard
> to a
> > > DAC, and let the DAC create the accurate CV that you need.  Another way
> would
> > > be to remove the rubber contact assemblies and build your own
> wire-contact
> > > switches to mount underneath the keys.  Neither of these solutions are
> neces
> > > sarily very elegant, but are workable nonetheless.
> > >
> > > Michael Bacich
> >
> >