Theatre organ control

I need to replace the old combination action on my theatre organ, which is a 50 yr old ferrite core memory. [yes...for you young pups, fine wires running through a matrix of ferrite core beads, with each bead 1 bit of memory]

I could use some help to determine if a Mega with 8 multiplexed I/Os will work for this application??

For those not familiar with what is needed, a large organ console has stop tabs which select the sounds played on the organ [which ranks of pipes will sound]. They have small coils which physically move the stop tab on or off, and there is a switch on the tab which actually selects the sound. There are buttons [pistons] on the console, underneath the keyboards, which will turn on the selected set of stop tabs for that button. So when you push a piston, all the stops in the memory for that piston will physically move to the ON position, and all the others will physically move to the OFF position. There will be a number of pistons for GENERAL, which will select the stops for all the manuals and the pedals, and there will be other DIVISIONAL pistons, which only select the stops for that particular keyboard or pedals. To program the combination action, there will be a SET piston. When the SET piston is pushed, along with whatever other piston you want to program, it will write into memory whatever stops are in the ON position for that division or general piston. Many combination action systems will also have multiple selectable memories for different organists to have their own preferences or for different types of music. There is also a general CANCEL piston, which moves all the stops to the OFF position.

There is a LOT of I/O required, since each stop has both an ON and an OFF magnet coil in it, there are a lot of pistons to select different combinations, and you need the feedback from the stop to be able to program the pistons. For this organ, this is about 365 points of I/O.

109 stops tabs [SAMS..stop action magnets], so 2 outputs required for each, and 1 input for each
37 piston button switches [12 general, 6 solo, 6 great, 6 accom-ped, 3 pedal, 2 trems. 1 cancel, 1 set]

Anybody think that this will work, rather than going with a full MIDI system built for the organ? Thanks

I'm not sure that I understand your description.

I think you are saying that there are 109 "switches" that need to be recorded as ON or OFF and 37 things that need to be controlled - each as either ON or OFF. Is that correct?

Assuming it is I don't understand how the 109 relate to the 37 - but I presume it is possible to write a table that describes the relationship.

And do you mean that there would need to be a recording (saving) of several sets of positions of the 109 "switches" so that any one of the sets could be selected when the organist wishes?

An Arduino Mega does not have enough I/O pins for 109 + 37 things but you can use external chips to extend the number of I/O pins that it can access.

My guess (based on what I think you mean) is that the saving of the positions does not need to be done very often compared with recalling and using the settings.

...R

I know the Mega itself doesn't have enough I/O to even come close to handling the requirement, but with 8 of the multiplexed I/O cards, there are enough of the Mega I/Os to drive the muliplex cards, and the DEV-11723 I/O cards will give me 48 I/O each, or 384 I/O points. They will obviously drive MOSFETs to provide enough current to energize the magnet coils.

For anyone not familiar with the technical aspects of organs, most people don't realize the complex control systems that go into them. Pretty impressive, since most of it was developed in the 1920s, and were by far the most complex machines of that era.

See the photo of the console. The organist will hand register, or flip down whatever stops he wants to be on [the multi-colored tabs on the rails, each a different sound or pipe set], holds the SET piston, then press one of the preset pistons [the white buttons directly underneath each keyboard]. that he wants to remember that selection. He will do that for all of the available preset pistons on the organ, both the general pistons, which will change the stops for the whole organ, or the divisional pistons, which will only change the stops for that particular keyboard. Then, when he's playing, he can quickly push one of the pistons, and it will immediately cause the stops tabs to move into whatever position is in the memory for that piston, and change the sound that he gets. For a large organ, it's the only way that an organist is able to quickly control the wide range of sounds available on the the organ while he's playing.

So basically, there are 36 piston buttons under the keyboards for the organist to push while he's playing, and each of those buttons will have a registration memory about where to position all of the 109 stop tabs [on and off signal for each of those stop tabs].

You need to be able to easily change the registration memory for any of the 36 preset pistons as the organist sets up the sounds he wants for each of the preset pistons, which may get changed often. So a critical part of the Arduino program will be for this ability to change the stop memory for any of the preset buttons, and "read" the whether a stop is on or off when the organist presses the SET button for that piston.

And they used to do this with a room full of mechanical relay stacks. Most of the newer organs use a MIDI system with special I/O and a host computer to run it. Hopefully we can find a cheaper way to fix this one with an Arduino.

If you want to see how an organist uses these.... Richard Hills plays Tiger Rag on theatre organ - YouTube

Images from Reply #2 so we don't have to download them. See this Image Guide

...R

You have not said whether my interpretation in Reply #1 is correct. And if it is not it would be helpful if you could provide a correct version expressed in similar terms.

I know what an organ looks like and I like the sound of them when played properly but that is the extent of my knowledge. There was a good organ in the chapel in my boarding school and there were a few, including one of the pupils in my year, who could play it well. I daresay it was not nearly as grand as the one in your pictures.

On the other hand, I know a little about computers and if you can express yourself in computer terms I suspect the problem is soluble.

Post a link to the datasheet for the multiplexed I/O cards you refer to.

...R

I think this is feasible and an Uno might work. As you said you can "expand" the inputs/outputs and I'm sure the Uno has more memory than the existing core (although some Arduino memory will be used for the firmware). The trickiest part is probably interfacing with the existing electronics.

rather than going with a full MIDI system built for the organ?

"Full MIDI", probably doesn't make sense. I would guess that if were to pay an expert to convert a pipe organ to MIDI it would cost almost as much as a new organ. But a MIDI-protocol control-interface is worth considering, and considering the scale of this project it's only a little more work and little more hardware...

I assume this organ is in a church or theater and you expect it to be around for many more years? If so, I'd recommend that you fully document your circuitry, wiring, and software. And, buy extra parts and build an extra controller board or two, so someone can repair/maintain this thing 15 or 20 years from now.

If this all works-out, you might want to convert the pipes to MIDI control. That is, allow it to be played with a modern MIDI keyboard (or computer). That's probably a 'manageable' project. The valves for the pipes are already electrically controlled, right? Converting the console/keyboard to MIDI is more daunting.

Thanks.

I just heard back from the manufacturer of the DEV-11723 multiplexer I/O cards, and you can't really stack that many on a Mega anyhow due the specific ports required, so it becomes a moot point. They said, in theory, you could possibly daisy-chain multiple I/O multiplexers, but then the address mapping would become unmanageable.

Back to the drawing board.....and time to get the scope out and see if I can find all the bad transistors on the 50 year old ferrite core memory boards.

In answer to your questions.......

I think you are saying that there are 109 "switches" that need to be recorded as ON or OFF and 37 things that need to be controlled - each as either ON or OFF. Is that correct?

Yes.....the 109 "switches" need to be easily "recorded" as to whether they are ON or OFF in memory for each of 36 possible selections [button 37 is a general cancel, which sends an OFF pulse to all of the OFF coils in all of the 109 stops].

Assuming it is I don't understand how the 109 relate to the 37 - but I presume it is possible to write a table that describes the relationship.

Each of the 36 preset buttons has memorized the on/off position each of the 109 stops should be in when it is pushed, then sends a pulse signal to either the ON or OFF coil to move each of the 109 stops to that correct position [the stop on/off pattern in the memory for that button].

And do you mean that there would need to be a recording (saving) of several sets of positions of the 109 "switches" so that any one of the sets could be selected when the organist wishes?

Yes, each of the 36 buttons will select a different ON/OFF pattern of the 109 stop switches.

An Arduino Mega does not have enough I/O pins for 109 + 37 things but you can use external chips to extend the number of I/O pins that it can access.

If I divide the system into blocks, the extension chips may give me enough to make it feasible, since I wouldn't need to access all I/O points from a single Mega. Something to investigate.

My guess (based on what I think you mean) is that the saving of the positions does not need to be done very often compared with recalling and using the settings.

Correct. The changes to the memory [associating the on-off state of the 109 switches for each of the 36 preset buttons] would only happen when the organist want to change a preset. That typically doesn't happen very much, compared to using them every few seconds when playing the organ. It does need to be able to be done quickly from the organ console by the organist when required, instead of by programming.

A little more background on how this came about....

This particular organ is an early 70s era Rodgers 340 electronic organ. I have 2 of them, and one is gutted, waiting for me to be able to afford the full MIDI conversion. Artisan Organs has all the MIDI driven I/O to connect and drive the stop tabs, keyboards, pedals, etc., along with the capture memory system. That organ will also get their sound engine with all the digitally sampled theatre organ ranks, which also controls everything else via the MIDI interconnects, with Linux based programming in the dedicated computer. That system will cost about $8K, and I didn't have the extra cash to spend on it right now.

The other organ that had been working is in my house, and the old ferrite core based capture memory system is a problem. The system was very innovative and "state of the art" for the '70s [the founders of Rodgers Organ came from Tektronix], but the very nature of the system makes it unreliable and difficult to troubleshoot, particularly when you are dealing with 50 yr old transistors that shift just enough in tolerance to cause intermittent problems. The analog electronic voices in the organ were actually pretty good, and still sound good, and it will be a good instrument if we can get the stop control system to work. So I'm trying to figure out a way to get the stop capture system to work with an Audrino, which is within my current budget.

Rogers Organs were made in Hillsboro, Oregon. One of their engineers was a member of the Portland Amateur Radio Club back in the 1970's when I was also a member. I wonder if I could remember his name and call sign?

Paul

sacfarmer:
Each of the 36 preset buttons has memorized the on/off position each of the 109 stops should be in when it is pushed, then sends a pulse signal to either the ON or OFF coil to move each of the 109 stops to that correct position [the stop on/off pattern in the memory for that button].

I had not appreciated that aspect of the problem.

If I understand it correctly the organist will set all of the 109 stops in certain positions and then save that set of positions so that it can be recalled by one of the 36 presets.

Then (and this is the bit I missed) when any one of the 36 presets is pressed all 109 stops have to move to their saved position.

That means that you need 109 "inputs" for when the stop positions are being recorded AND 109 outputs (or maybe 218) for when they are to be moved.

What sort of signal does a stop need in order to cause it to move? Is it a TTL level signal or is it a power pulse - for example to cause a solenoid to activate?

...R