Hypothetically add Velocity to MIDI keyboard with single analog input?

How would it work with chords? I'm not a musician, but don't musicians hold down keys for sustain, and then press more keys?

Chords work fine as long as the multiplexer is fast enough to see everything. All notes that get played get passed along in real time. Sustain is handled differently depending on the system. For example on an electronic organ you can make it hold the note as long as you keep it depressed, or you can make it decay like a piano. Suppose you have your inputs set up as drum pads but you want the output to sound like a horn - you may need to do a drum roll which would get interpreted as a sustained note, which is fine because a horn can only play one note at a time and it can't do a drum roll.

A real piano has a pedal to allow or kill sustain - a similar function can be implemented on a MIDI system.

Hi Doug,

With the switches effectively OR'd together (which is what I believe Ernie is suggesting by paralleling them), then it will not be possible to know the velocity of any key other than the first key that is pressed, because subsequent switched won't be able to close that OR'd switch circuit because it is already closed while the first key is held down.

For a normal chord maybe it won't matter if the musician wishes the keyboard to assume that all keys are intended to be simultaneously struck with the same velocity, but I just don't know (since I'm not a musician) if there is a requirement to have sustain while pressing additional keys. If there is, then OR'ing won't allow velocity determination for those subsequent keys. I could be talking rubbish! : ) I'm not very knowledgeable in music.

Good point Shabaz. That is sort of true, but it is possible to have a unique voltage result from any unique combination of keys. The number of keys that can be managed depends on the accuracy of your A/D. For example suppose you have a 12 bit A/D and 12 buttons. If each button corresponds to a bit in the A/D, the most significant button causes a 50% change in voltage and on down the line until the least significant button only causes 1/4096 change in voltage. Each button always causes a unique change in voltage that is different from all others.

It does get tricky when just using resistors to implement (you need a spreadsheet to figure out all 4096 combinations) - it would be a lot easier to deal with constant current sinks or sources.

I think MIDI sustain would normally apply equally to all keys pressed at the same time, (because it is convenient) but variability here might lend uniqueness to a musician or a performance.

Multiple simultaneous velocity is definitely a challenge with this scheme.

Sorry if my wording was tangled up in my description. All of the primary sensors are hooked up in a parallel circuit, each with their own resistor of the same value. As the first key or additional keys are pressed or released, the current in this circuit should, on paper, rise or fall in discreet increments. When the analog input determines that it has risen a given amount from the last reading, the time will be recorded. The controller would then "listen" for a reading from the second set of sensors, which are conventionally multiplexed as separate digital inputs, to get the pitch and the second time measurement.

As dougw mentioned, debouncing would definitely pose an issue. Perhaps this could be mitigated with some sort of a smoothing function/rolling average for the analog input reading? Another issue might be two notes that are played extremely quickly in succession (such as grace notes), and having both of their starts registered before either of them gets resolved, resulting in a solid chord (perhaps an array could solve this). Additionally, if a key gets pressed at precisely the same time another is released, it might not be detected.

Being someone who is very new to all of this, I am still working on breadboards, and find the prospect of making my own scan matrix pcb a bit daunting. The solution I have come up with at the moment is a Mega with a handful of 4051s attached to it, which would give me enough inputs for a non-velocity keyboard. I was simply looking for a workaround so I wouldn't have to double that number to add velocity.

Hi Ernie,

Oh, I see. Sorry, I had misunderstood, and had not realized you were encoding the the keypress with resistances. I guess it could work then, as Doug says. It will be hard though, processing your measurements at a fairly high speed (perhaps a thousand times a second) to get the timestamp of when the resistance changed, and keeping the changes significant enough to avoid error (e.g. using 1 or 2 octave keyboards, not 88 keys).

Yes. Again, the first switches don’t carry any information except how many total keys are being held down at a given time.

Another hairbrained idea I had was that each key both closes and then opens the circuit again in a single downward movement, and again in its upward motion. This could then be used to determine pitch, velocity, and note off with a single digital input. I still have no idea how I would implement that.

Yes. Again, the first switches don’t carry any information except how many total keys are being held down at a given time.

Another hairbrained idea I had was that each key both closes and then opens the circuit again in a single downward movement, and again in its upward motion. This could then be used to determine pitch, velocity, and note off with a single digital input. I still have no idea how I would implement that.