Keyboards design (off topic)

General
1

A somewhat off-topic post, but I have been considering how one might build a keyboard with varying action, including organ type trigger that occurs right at the top of key travel and the more typical synth type trigger with velocity detected near or at end of travel. These conflicting detection / trigger methods may seem challenging to implement on the same keyboard (using switch contacts) and indeed, most MIDI keyboards provide the synth or piano type of trigger. There are few (if any) that emulate the old Hammond B3 action where you could tickle the keys to sound notes, except maybe dedicated organs like the Hammond range.

Another feature could be partial triggering, like the B3 did. It had separate contacts for each tone wheel and partial press could make fewer contacts close, resulting in fewer tone wheels sounding and hence a lighter sound - a kind of velocity control but with a more random and tonaly different result.

I wonder whether the use of Hall effect sensors might allow such configuration? There could be a small magnet on each key near a sensor which would detect the distance the key is pressed. An algorithm and user configuration could then detect the velocity (wherever you want within the key travel) and / or the key position. This could allow that B3 effect by sending messages based on how far the key is pressed (near the top of travel) and also more complex control, like poly aftertouch or separate CC. (This could benefit from use of MPE.)

I reckon that you could retrofit such a system to an existing keyboard with small magnets (8x2mm) available for as little as £0.05 each and AH49E sensors for about the same cost. It may need several microcontrollers to scan the sensors sufficiently rapidly. These could probably be an 8-bit micro like the STM8 or maybe the 32-bit STM32 could offer some advantages, e.g. better handling of larger ADC words. These would probably be about £1 each with 8 ADC channels which, with no multiplexting would require 1.5 per octave. There would also need some interface which could be a similar microcontroller with serial (for DIN-5 MIDI) and USB (for USB MIDI). It could even have network (for MIDI over IP) but I probably wouldn’t bother with that. A few extra components for PSU and interfacing might make the cost of components somewhere in the region of £20 which sounds quite an affordable add-on to an old unloved keyboard.

There would need some method of configuration which could be via a UI (screen + buttons / encoders) or via USB and remote computer program.

I found this project on the Teensy forum which is very similar so there may be a lot to learn from following this. This uses a multiplexer to read 16 sensors so there may be the opportunity to reduce component count but I suspect dedicated microcontrollers per bank of keys may offer more features.

I have some keyboards kicking around which might find some magnets glued to their keys in the future…

2

Interesting to read the article results look very promising…

What do you think the most suitable micro with plentiful analog input would be…?

3

That project is on the Teensy site. I have asked a few questions but assume it uses the 16x1 mux to feed into a Teensy that has 10 ADC pins which would support all but the most ridiculously sized keyboards. He was getting a refresh rate of 1kHz on a 48 key keyboard (4 ADC pins scanning 4 off 1x16 mux) which is okay. Maybe a bit faster would be nice.

4

As a test project I built a pair of CC pedals (soft & sustain). Although it works quite well, calibration is challenging. There may need to be a method to calibrate each key and store that calibrate in persistent storage. The Bluepill board I used for this year does not have persistent storage (NVRAM, EEPROM, etc.) and I wanted to avoid writing to flash which has limited write cycles - although for this, it might be okay. One would hope that calibration only needs be done rarely.

5

I will probably implement EEPROM emulation in an upper range of flash memory with an ability to save any config data via an infrequent write process. If this data is only written once, e.g. during post fabrication test and calibration then it is no worse than writing the firmware. If it needs to be updated occasionally, e.g. a few dozen times through the life of the product then that also works but I wouldn’t want a general user config to be written on every use. Because flash requires whole page erase/write, I would re-write all config data in one hit. (Calibration data is likely to fit in a single page.)

I tried an automated calibration algorithm that initially seemed to work well. It intialised with power-on rest state values and estimated key-pressed value then pushed those range-limits as ADC values exceeded the limits but over time the limits got pushed too far, probably by noise or bad ADC data. (I have filtering in place to minimise this but it still occured.) So the device ended up with random data or failure to trigger. I feel there should be a way to do that reliably, maybe filtering the calibration data more aggresively than the live operational data, e.g. a range has to be exceded many times over a longer period before it is altered.

6

I think there would need to be a rubberised pad beneath the keys so that there is an endstop for normal playing then some movement for aftertouch but this might benefit from a conact as the range would be quite small.