Adding MIDI to Old Home Organs

In a previous instructable "How to Get a Free Synthesizer" I talked about how to obtain a "synthesizer" (a home organ) for next to nothing. So, maybe now you have your free home organ and maybe it looks cool but doesn't work properly or maybe it works properly but you're bored with the soundalike presets typical of old, top-octave synthesis organs.

Maybe you'd like to turn your organ into a MIDI controller! It's going to take some wiring, but if I can do it so can you. Then you'll have your vintage keys AND whatever modern (or vintage) sounds you like.

This project is specifically tailored to organs (or synths) which use a common-connection or what I call "bussed" keyboard. This is most organs built before about 1983. Organs built after 1983 began to use computer control over sound generation and started to use what is called a "matrixed" keyboard. More on this on the next page.

This project was produced for the 2012 Maker Faire in Raleigh, NC.

We have two types of keyboard wiring schemes used in all electronic keyboarded instruments:
- matrixed
- bussed

Matrix keyboards are how almost all modern keyboards are wired. It is most easily understood as a crosshatch of vertical and horizontal wires where the key is at every intersection. This method has the advantage of using the least number of connections but it must be scanned by some sort of microprocessor. 61 keys can easily be scanned with only 16 pins on the CPU. The microprocessor scans one row or column at a time but does it quickly enough it is fully transparent to the musician. the CPU then instructs whatever makes the sounds to play the notes pressed. No problem for today but 40 years ago it would have been cost-prohibitive.

Bussed keyboards have all the keys fed with a signal (usually a raw squarewave note fed directly from a divider chip) which then connects to a common connection. There might be more than one common connection. This may take the form of multiple key contacts or it may be some arrangement which pulls springs into contact with metal rods running the length of the keyboard.

The bussed keyboard type was the first to be used because of the way sounds were generated in the organ. The earliest organs used individual oscillators for each note. Each note was wired to a key, and when you pressed the key you were connecting the signal to the amplifier. Individual oscillators eventually gave way to integrated circuits which divided a master signal down into top notes and then all the lower octaves. Again, the final note outputs were wired to each key.

The reason for multiple bus rods/rails under the keyboard? You could have the dividers output a high frequency squarewave which could then be fed off to other divide-by-x circuits to create more simultaneous octaves. The voice tabs would turn on or off the inputs to the other dividers. Usually these were the "flute" or "tibia" sounds. They were labled by "footage", eg. 16", 8", 5 1/3", 4", 2" etc...

How are we going to connect all those key contacts to our CPU to convert them into MIDI commands? If we have 2x 61-key keyboards, that's 122 key contacts. No way does any CPU have even close to that. Shift registers to the rescue!

A shift register is an integrated circuit which converts serial to parallel data and vice-versa. This project uses the 74hc165, which is a Parallel Input, Serial Output (PISO) shift register. The shift registers "latch" in all the inputs at once, and then the CPU reads the data out of the string of shift registers serially, meaning one bit at a time.

We need 8 shift registers to handle 61 keys as the shift registers used have 8 parallel inputs.  We can't escape the fact that some serious wiring work is going to be needed to connect all the keys to the shift register inputs. The plus side is we only need three CPU pins to control and read the shift registers.

If we want to read more than one keyboard we can multiplex the keyboards with some extra CPU pins. What the CPU will do is change the state of the common buss connections on each keyboard so they are either grounded or floating and read one at a time. We use a 16 mHz CPU (actually a microcontroller) which can easily multiplex two keyboards and still have time to spare to read knobs, buttons and update a display.

The first step is to get the back and/or top off your organ and see what you're up against as far as wiring is concerned. The easiest way to handle this project is to decide that you will NOT be keeping the original functionality of your organ. It's possible to retain the original sounds but the difficulty in doing so depends if your organ sends the actual audio to the keys or just a control signal. If a control signal is used then it's not hard but if audio is present the conversion will be much more difficult. In any event, just something to think about but this instructable will only cover not keeping the original functionality.

Wiring is expensive, tedious and time-consuming. We can avoid as much as possible by trying to retain as much of the original wiring harness as possible. Since the sounds were most likely produced by octave dividers, you will likely find your wiring harness is not ordered by note but by "key", meaning all the "c"s are together, all the "d"s are together etc.. No one says you can not just scan that in directly and then figure it out in software, but if you want to use my code you have to sort the wires back into ordered notes. I found it made troubleshooting much easier to have my notes in order as they went into the shift registers.

Your choice for sorting out the wires is either use the existing board(s) or cut out the wiring harness at the sound board and solder it to a protoboard. I chose to use a protoboard (actually the guy who had the keyboard before me did). You will need to use the protoboard method if you want to PROPERLY scan more than one keyboard. You will need a diode for each key to prevent "ghost notes" and it is unlikely to be feasible to add that to the old sound generator board.

I highly recommend using either rainbow ribbon cable OR use teflon-coated wire. I think there must be teflon-coated rainbow ribbon cable but I have never seen it. Anyhow, rainbow wire helps keep your connections in order and teflon-coated wire insulation will not melt or shrink as you solder it.

I used Molex connectors because I had them on-hand and because you can push the Molex terminals out of the connector if you find you have made a mistake. I discovered too late on my breadboard version that my Molex connectors were not really end-stackable. I got around it by bending my header pins. On my hardwired version I did it properly by giving one 0.1" hole space between each connector.

Everything you need to for the project is here on GitHub:
https://github.com/quarterturn/organ-midi-project

There you will find a more detailed explanation of the project, as well as the Arduino 1.0 project source, modified libraries needed by the code and an Eagle schematic.

In addition to the organ of your choice and the 74HC165 shift registers, this project also used:
- Atmel ATMEGA328p on a Modern Device SBBB
- Wicked Device RBBB shield board
- 5v regulated switchmode power supply
- Modern Device Fluxamasynth single-chip MIDI synth
- HP Entertainment Center VFD
- 4x 50k pots (10k would be better)
- 2x pushbuttons

Check my github repository on the previous page to get updated libraries for the Fluxamasynth and HpDecVfd which work with Arduino 1.x and which provide some extra functionality (more control over sound parameters for the Fluxamasynth)

How does the microcontroller convert the information from the shift registers into MIDI notes?
As described earlier (in shift-in-midi-description.rtf, available on GitHub) , the microcontroller causes the shift registers to latch the data on each input and then shifts all 64 bits of data out of the registers. Here is the process for converting the shift register data into notes:

Note: this process runs continually in a loop, thousands of times per second

1. The shift registers are latched, reading the 61inputs all at once.

Note: logic gates always need a reference for high or low. Usually it is best to provide a reference to "high". This was necessary for early integrated circuits called "emitter coupled logic" or "TTL". It was much less wasteful of power to pull inputs high on these chips than to try to pull them low. When we say "pull" we mean to connect a pin to a current source or sink via a resistor. Typically 10K Ohm is used. So, in our case, every input requires a connection to the supply voltage (5 V) via a 10K resistors. This is a lot of resistors, but luckily, resistors are very inexpensive. So, when we latch in the inputs, if no key is pressed a "high" logic state will be read. We connect the shared bus to ground (actually a pin on the microcontroller set to be a low output, which acts as a current sink). If a key is pressed, it "pulls" the shift register input pin to a "low" logic state. This means a key being "on" is actually read as "off", which is backwards, but we can fix this easily a little later.

2. Shift register data is stored in an 8 byte array of current key state and previous key state.

Once the shift registers are latched, we start sending clock pulses. Each clock pulse causes the state of the shift register to shift one bit towards the output pin. Each chips output is connected to the input of the next chip. This allows the data to move sequentially through all the chips. But how do we deal with the "on is off" and "off is on"? The 74hc165 provides two serial outputs - a normal output and an inverted output. We connect the microcontroller to the inverted output of the last shift register. This changes the input states back to what we want - key down is "on" or "1" and key up is "off" or "0".

We are using an 8-bit microcontroller. It works best and most efficiently with 8 bits (one byte) at a time. So, we read the shift register data one byte at a time.  The eight bits in a byte store the key state of eight keys. We need 8 bytes to store the key states of all 61 keys.

We have to pay careful attention to how the data comes out of the shift registers. We wired our chips so the first registers first pin (input A) is connected to the rightmost key - we call that key "1". The last key is key "61". So, we are going to get the key states out of the registers in right to left order. So the first byte read is actually going to be the last five keys (and the three unused inputs). We wanted our bytes to be stored in left to right order, so we also had to make sure we put the first bit received in each byte into the leftmost bit of the key state byte.

You can do it any order you want, but you have to be consistent!

3. Key states are converted into push states; push states are stored in a 61-byte array holding either note on, note off or no change.

So, we have 8 bytes worth of key states for all 61 keys. But this is not exactly what we need to send MIDI commands. MIDI causes notes to sound with a "note on" command and the note stays on until "note off" is sent. So we have to convert the key state into a press state. We want to know when a key has be pressed so we can turn the note on and we want to know when a key has been released so we can turn the note off. We do not want to send "note on" thousands of times per second. That would flood the MIDI bus with data and it would not work.

To generate push states from key states we have to store the current key state and the previous key state. We compare the two each scan loop and see if the state changed. If it went low-to-high, then a push down is registered and a "note on" is sent. If it went high-to-low, then a key up is registered and a "note off" is sent. If nothing changed, no new MIDI data is sent.

We compute MIDI note information by storing a lowest note value and then adding the array index to it to get the actual note. This is the simplest way to approach it. If you want to get fancy you will need some sort of look-up table.

4. The process repeats. We make sure we wait a minimum amount of time between keyboard scans. If we scan too fast we will pick up what is called "key bounce" - electrical noise generated when the key contacts open and close. If we read it we will get spurious key state information. All we have to do is wait a little longer then the typical "bounce" period. If the bounce period (10 microseconds in this project) has not yet elapsed, we simply exit the scanning loop and try again.

How do we actually convert key states into push states?
In this project, we read the shift registers using software. This is called "bit banging". It is not the fastest method. There is a hardware facility in the ATMEGA chip called the SPI (Serial/Parallel Interface) which could do it much faster. However, it is harder to understand and it turns out for reading human inputs bit-banging is plenty fast. We make sure it is fast by using the microcontroller as efficiently as possible. We make all our key state comparisons using bitwise operators. The bitwise operators we use are "<<" shift left, ">>" shift right. "^" exclusive-OR (XOR) and "&" AND. XOR is used to see when key state within a state byte has changed when compared to the previous state. AND is used to select bits from a byte using a bitmask. The shift operators are used to move a bitmask bit left or right inside a byte to select a specific bit to compare. All these operations can be carried out in one or two clock cycles, making them very fast.

If you want to learn more about how the code works, take a look at the source. We provide plenty of comments on how each part works. Again, the most difficult part is simply making sure you read and compare data in the correct order.

Here's what the whole thing looked like at the 2012 Raleigh, NC Maker Faire, where it was presented.

Well, it sounds like whatever you have it hooked up to MIDI-wise. I used a Fluxamasynth, which is great for the price but is mostly single-sampled instruments so, uh, let's just say you wouldn't want to cut a record with it. But for what it costs and the convenience, it's great.

Note that this method of keyscanning, and they type of keyboard used, precludes getting a key velocity. Maybe you could do a retrofit which uses optical or hall-effect sensors and be able to get velocity. That's a whole other project though. Your best bet for sounds is therefore stuff which doesn't use velocity, like church organs, harpsichords etc... In fact, many times a beautiful but unfixable church organ will be converted to MIDI in this manner and then used with sampled instruments. Check out "jOrgan" - it's free.

I wanted to give a basic demo video but tragedy struck while I was working on fixing a dead key (due to a break somewhere in the wire for it). The keyboard fell off the table and got thoroughly smashed. Do you want to hear the sound of stuck keys? I didn't think so.

I have some other old keyboards around which I hope to hook up to my scanner so stay tuned, I may yet put up a demo!