Hi folks – I'm trying to come up with a circuit design that will essentially add MIDI capabilities to a non-MIDI keyboard. The keyboard in question uses an 8x4 scanning matrix – short 1x3 and it plays a B1, short 3x6 and it plays an F#3, etc...
Initially, I thought I would just connect a series of four multiplexers to the matrix and use the MUX logic to control the keypresses. But I soon realized that there would be no support for polyphony (two notes at once) if the two keys were both connected to the same MUX (since the MUX can only close one I/O line at a time). So I'm starting to feel like a MUX is not the right tool for the job?
Solid-state relays seem like a possibility, but that solution would be both bulky and expensive.
My electronics circuit-design knowledge is not strong. Does anyone have any suggestions for components and circuit logic that could solve this problem? Many thanks.
Look at the Keypad library. Find some projects that use it, to see some wiring options. Does your keypad have diodes? You need those for multi-keypress support.
Interesting library, but it looks like this is designed to take input from a keypad. What I want to do is send output directly into an existing key matrix.
CMOS switchers, such as the 74HC4066, 74HC405x series are what you need.
First question - is the keyboard already polyphonic and uses diodes? because a mechanical crosspoint matrix cannot support more than two key closures without diodes.
Basically you will have to provide one multiplexer pair (2 x 74HC4051) per note pressed. I cannot think of any other way at this point.
(Well, I can; it involves an Arduino programmed fast enough to monitor the scanning of the keyboard and generate the "closures" on the scan inputs, but that is extremely difficult to make work adequately. Maybe a FPGA.)
Four 74HC595 8-bit serial-in/parallel-out shift registers to give 32 outputs.
Eight 74HC4066 quad-bilateral switches allow each of the 32 outputs to connect a row to a column.
Yes, as you point out there's polyphony, but it's only two-note. I suspect diodes are in there since the circuit shouldn't be working as-is otherwise.
Full disclosure: this stuff is (literally) opaque to me because it's under a notorious epoxy blob. People are understandably confused by why I would go about this in such a backwards way – It's simply because the matrix is the only circuitry I have access to.
The more I think about it, the more I was coming to the same conclusion you suggest: two multiplexers per note register in order to retain polyphony. Or just give up and make the control monophonic with a simper circuit/
In that case, why not just use a microcontroller with at least 29 digital I/O pins, e.g. the Arduino Mega, the Arduino Due, etc.? Give every key its own I/O line, and get 28-voice polyphony for free. (Well, for the price of one Arduino Mega.)
(I suppose if you use the Due you could even implement MIDI over USB. Not sure if the Mega can do that.)
I do have an Arduino Mega, I'm just confused as to how this would work with the matrix? (I'm forced to the matrix on the keyboard) It's not enough to send a signal, I need to connect the appropriate rows and columns on the matrix.
Oh, right, I didn't quite understand what your requirements were.
Still, if it's just an 8x4 matrix, I don't understand why you even need a multiplexer? Just give each of the 12 lines to the matrix their own I/O pin, do a matrix scan, and remember each key's state during the last scan in code.
Do you want the Arduino to trigger notes instead of your keys being pressed so the Arduino can cause the keyboard to generate sound?
Or do you want to press keys on the keyboard and have that generate MIDI note on and note off messages to send to a MIDI system?
Is the keyboard, as it is, velocity sensitive, that is the faster you hit the keys the louder it plays? If so do you want to keep that for any one of the above two cases?
The whole thing about a matrix keypad is that the easiest is to address one side of the matrix as output pins which you turn on 1 at a time, and read the input pins from the other side. No need for much extra hardware other than current limiting resistors. You will need those, and also there will be a limit on your polyphony, unless you can make sure that current can only flow in 1 direction through a key (basically adding a diode in series with every key, which will probably not be easy)
Pressing 2 notes on the same row, while 1 of those is also on the same column as another key will result in a 'ghost' press of the key which is the intersection of the key that is in the matrix on the cross between the 2 keys which are on a row/column by themselves. There is no way around this anyway without the diodes.
You can't really. The way it is done with a normal midi keyboard is with 2 switches and the loading of a capacitor that starts after pressing the first and measuring the voltage after pressing the second. Where both are pressed by the same key and are sprung by a small spring.
Actually instead, put diodes on the OUTPUT pins with the Cathode facing the Arduino, and define the INPUT pins as INPUT_PULLUP. Make the Output Pins LOW one at a time and read the input pins. Still the 'ghost' presses can not be helped without a diode on every key.
The single wire on the right is what the piano key hits. The three connectors on the left are a single pole changeover switch with break before make contacts.
You detect the normally closed being open and make a note of the time. Then you detect the normally open being closed and subtract the time this happens from the initial break.
So in effect your matrix is twice the size of the number of keys that you have, as there are two switch contacts for each key.
So this describes the potential situation of a third keypress, the first two are no problem.
That would be an analog approach, requiring custom hardware; not particularly practical on an Arduino.
Suffice to say that velocity sensing necessarily requires two switches per key in whatever configuration that may be. One way would be a SPDT switch between Vcc and ground with the processor determining the intermediate state.
As I see mike goes on to describe; this could be incorporated in a matrix but due to the profusion of NC contacts, it absolutely would require the diodes. But the diodes are no problem for a musical keyboard, as it is not constrained to be a single integrated piece of contact material like a calculator or telephone keypad.
Mike clearly has more familiarity than me with keyboards - i have not pulled apart my Thomas "Jester" for a couple of decades. (It is pretty much "buried" in this room, sadly. )
Well, you don't need the diodes as you can make the I/O "open-collector" by writing it LOW and swapping between INPUT and OUTPUT modes. Internally, you write to the DDR instead of the output register. And there are not current-limiting resistors, there are pull-up resistors including the INPUT_PULLUP.
(It is pretty much "buried" in this room, sadly. 
)