[sdiy] MIDI velocity

Richie Burnett rburnett at richieburnett.co.uk
Thu Apr 7 00:21:15 CEST 2016

> What are some examples of commercial keyboards with ASIC solutions?

I just looked at a few old Yamaha and Roland service manuals, like the D10 / 
D50 / D70 and alpha Juno 2 for instance.  The keyboard and MIDI interface is 
managed by an 8-bit micro, but there is always a "gate array" with a small 
(2KByte) SRAM tagged on to it that actually drives and senses the velocity 
sensitive keyboard matrix.  I don't know how much of an active part the gate 
array and the tiny RAM chip play in measuring the key velocities though. 
Maybe the gate array is purely for I/O address decoding and glue logic, or 
even just to provide sufficient drive current to charge and discharge the 
capacitances of the switch matrix!  I really don't know.

> All of my (our?) favorite vintage synthesizers were designed with 8-bit 
> processors like the 6800, Z-80, or 8049/8051 running at about 1 MIPS. They 
> usually had a few 8-bit ports and all use a switch matrix for the 
> keyboard. Some of the Technical Service Manuals actually mention the exact 
> scan rate, and it's usually on the order of 1 millisecond. That's for 
> non-velocity-sensitive keyboards, so perhaps the scan rate is higher for 
> velocity. It would be interesting to find a Service Manual for a 
> velocity-sensitive keyboard that actually describes the scan rate. My 
> experience is with really old keyboards, so if anyone has pointers to this 
> information on velocity synths, I'd appreciate it!

Sadly none of the service manuals I've looked at give any timing diagrams 
for the scanning of the velocity sensitive keyboard.  I could feasibly crack 
open my Alpha Juno 2 and measure it if I had to, but a scope probe dangled 
over the keys with sufficient gain might show a hint of the scanning 

I'm also just about to scope the closure of the upper and lower switch 
contacts on the Fatar keybed that I intend to use whilst I hit the keys with 
varying degrees of force, to get some real data about the actual range of 
transit times.

> If you write your PIC timer interrupts in assembly, you should have no 
> problem trying higher scan rates.

That is my plan.

> I would recommend using a matrix where the two switches for any given key 
> are on the same column.

Unfortunately, that's not how the matrix is wired up on the keybed.  The 
"rows" and "columns" of the matrix are wired up differently.

> Since the two switches are at a fixed distance, you can consider the 
> distance to be "1." So, you're correct that it would be a simple 
> reciprocal. I think what you have here is a happy coincidence that affords 
> easy optimization. The desire to have multiple curves pretty much requires 
> a lookup table, at least on simple 8-bit processors. Since you're going to 
> have lookup tables anyway, you might as well incorporate the reciprocal 
> calculation in the lookup, and thereby avoid a multi-cycle division. 
> Otherwise, you'd calculate the reciprocal and then do a lookup anyway. 
> Might as well build in the calculation that's expensive.

Yes, it makes sense to wrap up all the difficult stuff in a pre-calculated 
lookup table.


More information about the Synth-diy mailing list