Latae Organi

This is a work in progress...

A reed organ, a.k.a. pump organ, is a marvellous instrument. We have lots of them in Finland, usually they are over 100 years old and in playable condition. The function is simple. You operate two bellows with your feet. The bellows suck out air from a windchest, which stores negative pressure. A key on the keyboard opens a valve, which lets air get sucked into the chest. The air passes a brass reed, which starts to vibrate and generate a tone.

To make an automated reed organ, one needs to attach a vacuum cleaner to the chest and a servo motor to the key. A typical reed organ has 61 keys, or 5 octaves. One would need 61 servo motors. The PCA9685 servo driver can operate 16 servos. Four daisy chained drivers can operate 64 servos. If 61 servos go to the keyboard, I have 3 spare ports that can be used for actuators for the organ stops or for control lights.

The organ

My organ is manufactured by E. P. Carpenter & Co., USA, in 1902. It is important to choose servo motors strong enough to pull down the keys. The force and travel needed for each key can be measured. The force is not big, but if one uses octave couplers on the organ, the required force tends to get trippled. The datasheets of different servo models can tell the force and speed of the servo motors.

My organ has a beam just underneath the keys, suitable for attaching the servos. The shorter black keys can have their servos attached along one side of the beam, while the white keys have their servos along the other side. In a similar project (check here), extensions have been attached to the black keys to get all actuators at the same line.

To attach the servos, I picked away each key. This way I got to plan where I'd shoot the staples to hold the pulling strings. Each key pushes a pin downwards. The pin goes straight through the machinery and opens a valve. I accidentally pushed one pin too far down and the valve jumped off its position. That's whay I had to remove the whole machinery to get to the valves. But it made it very easy to attach all the servos when the whole machinery was removed.

A short string of wound thread from the servo horn will pull the key down. Careful designing of how the servo, the servo horn, the thread and its attachment to the key will fit, as well as the vacuum cleaner hose, will allow you to continue using the organ just as a normal pump organ.

Operation of the servo

When the key is pressed, first it travels a bit, then the valve starts to open. It travels further to fully open the valve. After that it still travels to the bottom position. If the organ is only to be used as an automatic organ, the servos and the pulling thread could be attached only to allow the key to move between the positions where the valve starts to open and where it is fully open. But that would affect the normal playing. If the servos pull the keys too slowly, one would need to define at least three crucial positions for each servo. The rest position, when the automatic mode is not used, where the servo horn goes to its upper most position to allow normal playing. The alert position just above where the valve starts to open. And the fully opened valve position.

No matter if one wants to optimize the action speed of the servos, one needs to adjust each servo after attaching everything. A hobby servo normally operates in a 180 degree sector. Before attaching each servo, have the servo turn to position 90 degrees. Do this by connecting the servo to a microcontroller. Don't do it by twisting the motor from the servo horn, you might damage the cogs of the servo. After that, attach the servo horn so that it lies in a horizontal position when the servo would be attached to the organ body. Check the distance from the servo horn (the hole you chose to attach the thread to) to the key.

What I did was I tied a piece of thread, some 20 cm, to the servo horn, glued the knot, measured the needed distance to the key. Then I picked away the whole key and attached the thread to the key using a staple gun. Before shooting a staple, I placed a piece of textile adhessive tape on the thread. It was easy to keep the thread in place. And the tape gave some protection to the thread against the metal edges of the staple. Then I made a knot around the staple and secured the knot with glue. I checked that the length was perfect and adjusted the length of the thread for the next key, until I was confident that the length I used was perfect enough.

After 61 staple shots, I had all keys on my table with the attached servos pending from short strings. I started to reattach the keys, starting with all black keys, because their servos were to be attached behind the white key servos. I used simply a hot glue gun.

Adjusting the servos

The white key servos were attached in avertical position, the black key servos had more space, so I attached them horizontally, allowing a bigger glue area. Some servos will rotate clockwise to pull, some operate counterclockwise. Some pieces of thread came to be longer, some shorter. In the end I still have to adjust each servo. Each servo will have its own upper position and lower position. For this, I need a special tool program.

Blynk

Instead of attaching extra hardware, like a potentiometer or a joystick (I considered both), I decided to use Blynk, to adjust each servo. But I couldn't get Blynk to work with the AVR-IOT WG. Seems Blynk is not compatible with the Atmega4808 microcontroller used by the AVR-IOT WG board. Fortunately I have an Arduino MKR 1010 Wifi. Since the servos are operated through the I2T, I should easily be able to replace the AVR-IOT WG with any board capable of I2T.

In short, Blynk lets you design a graphic user interface with buttons and slides and whatnot on your phone. Running the interface will connect your phone to your control board (in my case the Arduino MKR 1010 Wifi) through the Blynk server somewhere in the world.

This is my Blynk interface:

The two slides adjust the upper position and the lower position of each key. The values go from 50 to 700. I didn't bother to actually use angles 0 to 180 for the servos. Instead I just used duty cycles. The PCA9685 servo driver is actually a LED driver, where one can adjust the PWM duty cycle from 0 % to 100 % by adjusting on and off times in a 4096 step cycle. A typical hobby servo works by receiving a 0.5 ms - 2.5 ms (or 1 ms - 2 ms, it varies) pulse every 20th ms. The length of the pulse determins the angle. So, setting the frequency of the PCA9685 output to 50 Hz and adjusting the duty cycle between some 200 and 400 out of 4096, will adjust the angle of the servo.

The Blynk program in the Arduino

The program starts off with values 295 and 320 for the upper and lower positions of the servo. The program sends continuously a note on (lower position) for 600 ms and a note off for 300 ms. Adjusting the sliders has an immediate effect on the values. Stepping to the next key will store the adjusted values in an array, which I can print any time to the serial console to be later hardcoded into the code.

Reassembling

I did a first adjustment of the key action while all keys were reassembled and the machinery still was away from the body. But I couldn't see the black key servos and their pulling strings. I just did the adjustment according to how the keys moved. After that I reassembled the machinery and did a new test while I could get sound from the organ. Some keys appeared to be too low. The servo horns had to start from the uppermost position, which made the movement a bit too slow. And the valves still let some air slip, making the reeds whisper.

I was running out of time, so I reassembled all keys without testing. What I should have done was assembling the black keys first, then testing them. If they worked, I could have continued with the white keys. Now I assembled the black keys first, because their servos were to be attached in their own row behind the white key servos. And without testing, I continued with the white keys. Only after that I reassembled the whole machinery. With some whispering reeds I consider cutting their pulling threads and fixing them later.

Preparing tunes

MIDI is the obvious choice for music format. But whereas MIDI contains loads of parameters and whatnot, my organ is a simple instrument without very much use of channels or tracks, controller data etc. I thought of implementing just a few things. Since most MIDI implementations forget the actual Note off event and instead use a Note on event with velocity 0, I'll do the same. I want to edit music using Musescore. In Musescore, I want to write either on a piano stave, on a three stave organ stave or on a four part choral stave. Whatever I write, I want to export it as a midi file. The midi file might contain midi tracks, one track for each stave, but everything should be merged into one single list of events, sorted according to the event times.

To make sure I can save as much as possible, I have my own reduced data structure for midi events.

The structure looks like this:

struct miditype
{
    unsigned long ts1;       // delta time (midi ticks since previous event)
    unsigned char eventtype; // 1 : note on, 2 : tempo change
    union
    {
        unsigned long tempo; // new tempo (500000 equals 120 tempo)
        unsigned long track; // track number (for future use)
    };
    unsigned char key;       // midi key number
    unsigned char velo;      // velocity 1 - 127, zero for note off
};

The tempo change is not related to any track, therefore I use the same bits for either the tempo or for the track number. No midi channel data is used. The track number of each note on event might be of interest. I could filter some tracks, if I only want to play the melody. Or if I want to omit the melody and sing it instead. And since Musescore places different staves in different tracks, not in different midi channels, I've implemented the tracks instead of channels.

I wrote a four stave choral arrangement and ended in this array, which I hardcoded into the scetch:

miditype events[900] =
{
{ 0, 1, 1, 71, 80 },
{ 0, 1, 2, 68, 80 },
{ 0, 1, 3, 64, 80 },
{ 0, 1, 4, 52, 80 },
{ 0, 2, 588235, 0, 0 },
{ 455, 1, 1, 71, 0 },
{ 0, 1, 2, 68, 0 },
{ 0, 1, 3, 64, 0 },

According to the miditype struct, each line contains the time stamp (as a delta time to previous line), event type, the track number or the tempo, the key number and the velocity.

We see a chord of midi notes 71, 68, 64 and 52 starting at zero time. The fifth event sets the tempo to 588235. That means a quarter note lasts 588.235 ms, or 102 beats per minute. After 455 midi ticks the next events take place, which is note off for the notes that started at zero time. The tune came to have exactly 900 events.

Preparing the final reduced midi array

After writing the music in Musescore with tempo changes at the end, I exported everything to a midi file. I ran Midicsv.exe, a Windows console program that converted the midi file into a csv file. This is the content of the csv file:

From this table it's easy to delete all events but the note on events and tempo change events. In the csv file (as well as in the original midi file), all events are sorted so that the first track comes first, all the way from the beginning to the end of the tune. Then comes track 2, 3 and 4. But I wanted all events sorted according to their event time (column B):

Now we see the track number in the first column and the tempo change in the 4th column. To save one or two bytes per event, I combined the track number with the tempo, since no event need both values.

Another thing I decided was to replace the absolute midi tick values with delta times instead. This made dealing with tempo changes easy.

Velocity?

I can draw a crescendo in the score, but that only causes gradual changes in consecutive discrete note event velocities. On a reed organ, a crescendo and diminuendo can be achieved with levers that open small lids inside the organ. I still have some spare servo ports that could be used for this. But that would need either to calculate an average velocity and a smooth velocity change over a certain time range. Or having the crescendo act to a midi control change (CC) like channel volume or some master volume, which yet has to be somehow included in the midi export from Musescore. This I leave for further improvements.

The vacuum

I have left this part of the project to the last thing to implement. And now I've run out of time. So this is just a description of what I'm going to do later. For now, I'm going to use the foot bellows to make the organ play.

For the vacuum I drill a 30 mm hole in the windchest to fit the vacuum cleaner hose. The vacuum cleaner itself is a rather silent model. It has its own slider for electronically adjusting the motor power. In its lowest position, the motor is really silent. If it still sucks too much, there's a sliding valve on the hose, which further diminishes the sucking power. If one can't get the sucking power low enough, no harm is caused to the organ, since the windchest usually has a special valve which opens, if the negative pressure is too extensive. Another ineresting approach would be to power the vacuum motor with two or three acid lead batteries. Vacuum motors are often so called universal motors, which run both on AC and DC power. So if the motor is meant to run on full RPM at 120 V or 240 V AC, it might run fast enough for a reed organ at 36 V DC.

The hole should of course be equipped with a lid to be closed when the organ is played in the normal way. Air sealing the lid is not very crucial, since the windchest works with negative pressure. It helps to suck the lid tight onto the hole.

Tripped on chalklines

Unfortunately I couldn't get a demo ready before deadline of one contest. Too many bleeding valves made the organ unplayable. Have to fix it... Any day now...