[sdiy] MIDI velocity

[rsdio at audiobanshee.com]

On Apr 9, 2016, at 5:47 AM, Ingo Debus <igg.debus at t-online.de> wrote:
> Am 07.04.2016 um 01:01 schrieb rsdio at audiobanshee.com:
>> That means you cannot simultaneously read both. But an interrupt could feasibly read two columns in succession for nearly simultaneous reading.
> 
> I still don’t understand the benefit of being able to read both switches of a key simultaneously? They don’t close (or open) at the same time, that’s the whole point of measuring velocity. Do you want to stop scanning the keyboard once an active switch has been detected, and poll the corresponding switch of the same key until it’s active too? But still, this could be done if the two switches cannot be read simultaneously.

There isn't necessarily a demonstrable benefit. Call it a hunch. In my assessment, it removes an extra set of variables, and it seems like that would be good. It's not a strong enough hunch that I'd bother designing new PCBs for a key bed!

Here's what I'm thinking: If you read each switch on a separate column, then you have an additional variable of the time between reading the first switch and reading the second switch. That's in addition to the time between each scan of the same switch. If the matrix were wired with both switches for each key on the same column, then the timing calculation would be simpler.

It's probably not necessary though, mostly because the velocity keyboard only has 3 valid states for the 2 switches. The 4th state isn't physically possible unless something is broken. If you somehow get from state "0" (UP) to state "2" (DOWN), then just assume maximum velocity.

The idea of placing the switches in the same column of the matrix originated with rotary encoders, where all 4 states are valid and it's generally better to read both simultaneously. It's not even strictly necessary in the encoder situation, because the only way for a problem to occur is when a state is missed, and that generally means that the scan rate is too low.

Brian Willoughby
Sound Consulting

p.s. As I mentioned in an earlier message today, I don't see how it would work to stop scanning the keyboard once an active switch had been detected. Unless I'm missing something, this sort of algorithm would sacrifice timing accuracy any time a second (or third, or more) key is activated after the first switch becomes active. I'd be really curious if someone can describe a successful implementation of this scan stop method.