[sdiy] MIDI to Scanned Keyboard

[rsdio at audiobanshee.com]

On Aug 24, 2016, at 3:19 PM, Tom Arnold <xyzzy at sysabend.org> wrote:
> On Wed, Aug 24, 2016 at 02:50:39PM -0700, rsdio at audiobanshee.com wrote:
>> If you're going to retrofit a MIDI keyboard to replace the analog j-wire, I would highly recommend skipping any sort of faked switching. Instead, find the CV out of the ancient keyboard and use a MIDI-to-CV converter from your MIDI keyboard to the old sound generation modules. If full velocity support is there, then there should be a CV for pitch and a CV for velocity. Any decent MIDI-to-CV converter should be able to handle that.
> 
> There is no CV.  Its all scanned digital thats why I think I'm stuck
> emulating this at the bus layer.  Well, unless I can find 35+ year old
> source code... ( *insert lots of laughter here* ).
> 
> Having had a month to ponder this, it won't be very difficult actually.  I
> just haven't had time to write any code to try it.

I see. Are you working with the Alpha Syntauri hardware? That would probably have 1 microsecond resolution at the finest, based on the ~1 MHz Apple clock, unless there were external timer/counter circuits beyond what could be handled in software.

You were probably worrying too much about timing. Polyphonic keyboards are scanned in rows and columns, so even if you play all the notes of a chord simultaneously, the key matrix scanning will only pick up the keys in scan groups. In other words, there's already some delay between switch contact and actual response.

Of course, adding a MIDI keyboard and faked switch contacts will increase the latency, but I have a hunch it won't be that bad. A little concern is prudent, since the time delay between velocity switches is probably many times the delay between one column scan and the next (otherwise the velocity couldn't be measured).

If you were designing in a vacuum, you'd have to allow for the minimum and maximum time for any keyboard player's style, but in this case you only need to generate the timing range that can be measured by the old interface card. If the interface software has different velocity response curves, you'll want to measure each of them to find the extremes. You might start with a prototype circuit that can generate a wide range of timings, and see what it takes to generate minimum velocity and maximum velocity. Then you can refine your circuit for maximum resolution between those extremes (rather than wasting precision on out-of-bounds values that are beyond the minimum or maximum that can be measured by the old interface).

As for the circuit, I'd make the logic such that it's impossible to close both of the velocity switches for a single key at the same time. That might confuse the old interface if it detects impossible switch closure patterns. Analog switch chips that are wired for SPDT would probably make the most sense, and could be wired just like the J-lead.

Let us know if you get anything working, and what the project is.

Brian