Allen organ project - a software card reader [UPDATED]

Earlier posts in this series:

• Allen organ project - introduction


• Allen organ project - reverse engineering the card format

First things first. I can live without alterable voices for a short while. But these IBM cards are getting yellowed and brittle. They're 35 years old, and it's not going to be many more years until they crumble to dust. How to get the data off them? Transcribing by hand, the way that I did the first couple is not going to work. I know myself, I'll make too many errors and get eyestrain. There has to be a better way.

I don't want to make any electical modifications to the organ until I know more about it. I don't want to find myself frying some key irreplaceable part. So cobbling some interface to the card reader on the organ is Right Out. Similarly, the handful of services that are still out there who will read card decks are getting Really Expen$ive - I don't want to go that way either. So, what do I have that will read cards?

How about my document scanner? It'll read anything. (No, I haven't scanned my nether regions. It's been a long time since I was a college kid, and about as long since I'd have thought that was funny.) But I have experimented with scanning photographic negatives (only mixed success), coins (too much reflection), and pressed flowers (left residue that was hard to scrub off the glass). Maybe I'll have better luck with IBM cards.

Immediately, I make the executive decision to put the card on the glass face up. All the printing on the card will add visual clutter and confuse any image recognition that I try to do. The back of the card is cleaner, albeit not nearly pristine. But let's give it a try. I also decide to try to give the card a clean, contrasting background. I riffle through my stash of coloured papers and pull out a sheet in robin's-egg blue that contrasts nicely with the yellowed paper of the card. I set the scanner for color at 150 dpi resolution, push the button, and out comes:





Not bad, there's plenty of contrast. There are also a lot of specks of schmutz on the card. Let's hope that doesn't make for a bad read.

Believe it or not, from here things ran pretty much in a straight line. Everything I tried worked once it was debugged. (Of course, I have had to do computer vision at several points in my career, so my educated guesses about what to try are usually pretty good.) Here's an outline of how the program took shape:

1. Segment the image.
I used the k-means algorithm to divide the pixels into three categories: cardboard, background and schmutz. To seed the clusters, I started with an initial guess that cardstock is yellow, background is cyan, and schmutz is black. The algorithm converged quickly (only about ten iterations), and resulted in a segmentation that looked quite usable:



(In the image, white is cardboard, black is background, grey is everything else.) Again, it looks usable; the vast majority of pixels are classified correctly.

2. Extract edges from the image.
Given the segmentation, extracting the edges simply means highlighting pixels that differ from their neighbours above or to the left. Easy.

3. Find straight lines among the edges.
We're trying to find a frame of reference for the card so that we can lay the grid of holes over it, despite the fact that the position on the scanner glass was uncertain. A first step is to find straight lines. To do this, I use an integral transform called the Hough transform.

The Hough transform works by shooting bundles of parallel rays through the image, at angles ranging from zero to π. It counts the number of pixels marked as being 'edges' on each ray.

Update: One colleague called me on the lack of mathematical rigour in this discussion. Another praised me for an immediately-graspable physical analogy. To the first, I say: I could have begun the discussion with a sentence like, 'The Hough transform is the integral,

.'
But I didn't."

The result is a plot of pixel counts, with the horizontal axis being the angle of the ray and the vertical axis being the distance of the ray from the centre of the image. The rays that go right down the edges of the card have a great many edge pixels on them, and show up as brilliant white spots in the plot in Hough space.



In this plot of a card in Hough space, you can see the angle of the short edge of the card as a vertical column of points near the center of the image. The short edges of the card are represented by brilliant white spots near the top and bottom. You can also see the spots representing other vertical lines on the card (vertical rows of holes) in the same column, giving us a way to measure hole spacing, since the vertical axis is measured in pixels. The long edges of the card fall in a column near the right-hand border, and once again you can see other lines (the card rows) of 'edge' pixels in the same column (and therefore representing parallel rays). These are the rows of the card, and again give us a convenient ruler for laying out our grid.

4. Lay out a grid parallel to the card axes.
Given the maxima in the Hough image, which represent the card edges, it's a simple matter of trigonometry to locate the card corners and create a grid to search for holes, given the known dimensions of an IBM card.

Update:A colleague asked me how robust this process is in the face of card misalignment. I took a near-worst-case misalignment (the card canted about 30° from the correct angle), and did a quick hack to the code to overlay the computed grid in red. It's not perfect, but that's mostly because the card edges are modelled as parallel lines - and are not quite parallel (or indeed, quite straight) in real life.

5. Count up how many 'background' pixels are in each hole location, and threshold on the background-to-total-pixel ratio.
This operation gives us the location of the holes. And it worked first try! (Well, once I fixed the typos in the dimensions of the card, it worked. The algorithm was fine, the numbers were wrong. Garbage in, garbage out.) As a little bit extra, I added a decoder for the Hollerith data at the right side of the card (Allen's part number, plus some number whose significance so far eludes me.) The resulting program prints out an ASCII picture of the card, and saves the 16 words of binary data.

         11111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
--------------------------------------------------------------------------------
      8  8  8  8  8  8  8  8  8  8  8  8  8  8  8  8               20.0 S00R1305
                                                                     ]          
                                                                           ]    
              ]        ]        ]  ]     ]        ]        ]        ] ] ]]]   ] 
     ]     ]  ]  ]     ]           ]           ]  ]        ]                ]   
     ]  ]  ]        ]  ]        ]        ]     ]           ]       ]    ]       
           ]     ]     ]  ]     ]     ]        ]  ]        ]         ]       ]  
           ]           ]     ]  ]  ]        ]     ]        ]                    
     ]           ]     ]              ]  ]        ]        ]                   ]
     ]           ]     ]        ]     ]           ]        ]                    
                                                                                
      ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]                 ]          
     ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]  ]                        ]    
--------------------------------------------------------------------------------

Beautiful, it exactly matches the punches. Now to try recovering more cards!

Read more...

Allen organ project - reverse engineering the card format

Earlier post in this series:
Allen organ project - introduction

It looks as if a necessary first step here is to figure out the format of the data on the cards. Fortunately, the data didn't seem too difficult to reverse engineer.

Here's a bad picture (I'm far too lazy to shoot a better one, since this shows what we need to see) of two of the voice cards. To my ear, both of them sound nearly like sine waves, the Blockflöte at eight-foot pitch and the Flûte at 4-foot pitch.

The first thing I notice is that the large blank area at the middle right of each card is where the reading stops. (The card doesn't go into the reader any farther than that.) So only columns 6-52 (1-5 are blank) appear to be significant for the voice. (The remaining columns are Hollerith-encoded and appear to have a part number for the card and perhaps a few characters of additional information).

The bottom two rows, rows 8-9, of each card appear to have some sort of timing information. (See below - there's more insight to be had here.) On every card, they appear in a regular pattern: 9, 8, space, 9, 8, space.

The only other rows that are punched are 0-6. 7, 11, and 12 are always blank. On the Blockflöte card, you can sort of see a sine wave pattern running in the shape of the punches. This immediately made me guess that row 6 is the most significant bit of a 7-bit binary word. Plotting out the Blockflöte with this assumption gave a graph like:



Looks as if I guessed nearly right, except that this is only half a cycle. Let's see what happens with the flute. Here, row 6 is doing something strange, but I notice that the blank columns above it are moving in a sinusoid? Making the guess that it's two's complement, I plot out the binary numbers there:



Wow, a perfect sine wave!

I'm going to guess from the half-cycle of the 8-foot stop that the electronics in the organ use symmetry to make another half cycle from the samples that are supplied. For the resulting curve to be continuous and smooth, the second half cycle would have to be both inverted in level and reversed in time, so that the complete Blockflöte waveform would be something like:




We'll see whether I'm right if I ever try to make my own voices.

Now what about those timing tracks? I'd have a hard time designing circuitry to clock accurately a card being pushed and pulled by hand - it would be like clocking hand-sent Morse code (a difficult problem!). But wait a minute. Suddenly I remember that when I took a look at the card reader, the lamps seemed slightly
askew. It seemed awfully sloppy construction for a top-of-the-line (for its time) organ like this one. Looking back at the picture, I see:





I can see that rows 11 and 7 are unused, as I expected. Row 12 has a lamp over it; I'm guessing this row is used as an indicator that there's a card in the slot.
Certainly, with that lamp burnt out, no cards are reading, even if they have
no punches in row 12. Row 8 is displaced by about half a column from the others? What will this do to the relative timings? Aha! With the displacement, the row 8 signal will slightly overlap the row 9 one, giving a quadrature encoding that should be completely self clocking! Clever fellows, those Allen engineers. I'll have to remember that when I start blinking LEDs at the thing. I also make an educated guess that the reader is designed to operate on the pull, rather than the push. It's nearly impossible to push the card in evenly, but it's easy to pull smoothly.

Read more...

Allen organ project - introduction.

Those who know me will most likely already have heard that this spring, I bought an Allen church organ - one of the very earliest digital organs made. (A similar one is in the Smithsonian; the model is that significant to the history of organs.)

Well, let's just say that it's a very fine instrument, but showing its age in several small ways. Like any engineer, I have the attitude: "If you don't like the world, modify it!" So I've got a big fun project to keep me occupied for the summer. (In whatever spare time I'm not spending in trying to learn to play the thing!). So let's have a look at what I'm looking to do.

One particular period feature of the organ is that the alterable voices (wavetables in the early 1970's were novel technology!) are programmed with IBM cards, inserted manually into a little slot to the right of the manuals. Each card has a binary encoding of the waveform produced by a specific style of organ pipe.



I have dozens if not hundreds of cards for it, and they're getting rather fragile. 35 years ago, they weren't making punch cards to last for the ages. Moreover, the card reader has acted up twice for me. The first time, it was just dust and dirt obstructing part of it, and a can of air repaired it nicely. More recently, it's just quit. Time to investigate.
Getting to the card reader was a fairly simple matter once I found the two screws (one on each side) that hold the lid of the keydesk in place. The lid then swings up. If you try this, make sure you latch the music desk in the 'down' position first!

Once the lid is up, the stopboard is held in with two screws, one under the Pedal stoptabs and one under the Great.




With these screws out, it swings up out of the way.





Now the Swell manual simply lifts up:



Lifting the Swell manual reveals the card reader underneath it. The reader is held in with a card-edge connector and four screws. A quick test with the power switch reveals that one of the row of incandescent lamps on the top of the reader is burnt out.

Well, obviously that is one piece of technology that can be upgraded. Put LED's in there instead, and never worry about another burnout. But now a light bulb (or perhaps an LED, this is the twenty-first century) goes on over Kevin's head. This little lamp bar, easily removed, is the key to eliminating the deteriorating IBM cards without any electrical modifications to the organ. Pull out the light bar, and replace it with an LED bar with the LED's sequenced by a microcontroller as if the card was being inserted and withdrawn. And thus is born the Allen Organ Card Reader Upgrade.

Few good ideas are truly new. A little bit of trolling through the search engines shows that this idea is the subject of U.S. Patent 4,416,177. Fortunately, that patent is expired, and so there should be freedom to operate here. I'm essentially replicating exactly the device shown there, only with modern components.

Read more...