Keyboard Scanner Option

[ibanman555]

I would like to discuss the option of adding a keyboard scanning function to OpenDeck. My primary interest in this is to revive an old product from the early 1990s, the Lync LN1000 "keytars". I have 3 of these in a warehouse that were used in concert tours for a popular band and since they are over 30 years old now, they have started to malfunction. I thought that using the OpenDeck platform would be a great option to replace the heart of the controllers, but still keep the incredibly resilient ABS body and keybeds intact! If all goes well, I could put these back into use with the band!

These keybeds provide velocity, which is accomplished by essentially activating two buttons per key press. The elapsed time between the two button presses decides the amount of velocity for the note. Here is a PDF of one example with an explanation and another scheme of how this works:
https://github.com/oxesoft/keyboardscanner
PSR530.pdf

I'm hoping that there could be a specific option to configure OpenDeck to do this. It would make for a great option to revive these keyboards, but also allow someone to make a custom midi controller with a keybed as well!

[paradajz]

Supporting something like this isn't really in line with what mainline OpenDeck is for, which is a generic MIDI controller. This seems more like custom work to me.

That being said, I guess at least part of this could be made generic, that is, part of the mainline firmware. I could implement an option to transform two button inputs into a single button with velocity (with velocity being the time difference between those two keys being hit). That alone isn't really enough since another option would probably be required to fine tune the response / velocity calculation - most likely different hardware has different spacing between the two keys providing velocity, maybe the keys are shorter / longer etc. Doable in any case.

As for actually connecting this to an board running OpenDeck, it would require a dedicated driver for this keyboard in the low-level part of the firmware. Sure, doable, but like I said, I don't really want custom stuff in mainline firmware, unless you can prove me wrong on this. Maybe all keyboards with this kind of velocity implementation use similar technique? In that case I'd be willing to make it an official part of the firmware.

[ibanman555]

Thanks for your thoughts and opinion none-the-less. I can't say for sure that all midi keyboards use this two-button configuration for velocity (FSR or piezo could certainly be in some), nor do I see this benefiting any other knob, switch or trigger. Since a keybed is considered a midi controller too and often partnered with knobs, pots and encoders in most commercial products, I thought it might come in handy for someone in the future.

[ibanman555]

For what it's worth and if it helps clarify the physical action of a velocity sensitive keyboard, here is what I found , an explanation of how they indeed work:

There are two types of scanrow velocity-sensitive contact systems. The first is known as change-over. Each key has change-over (SPST – Single Pole Single Throw) contact. When key rests up, the upper throw makes contact, when key rests down, the lower throw makes contact. When key moves, first upper throw breaks the contact, then lower throw makes contact. When key moves up, first lower throw breaks contact, then upper throw makes contact. While key moves between these two points, none of throws makes contact. The second type is known as double (parallel) contact. There are two normally open contacts per each key. The upper contacts gets actuated at about 10% of key travel and the second contact is actuated at about 90% of key travel. When key rests up, none of contacts is actuated. When key moves down, first upper contact makes contact, then lower contact makes contact. When key moves up, first
lower contact breaks contact, then upper contact breaks contact.