An Unexpectedly Long Journey
It all started with the feeling of guilt. As the only organist at my small church, I felt guilty when I went away on holiday. There was no-one to play and so the services were rather quiet.
The year was 1997. The “organ” was a Compton Cantata – complete with electric motor, drive belt and spinning generators! I was looking for a replacement organ but, as a temporary measure, I purchased a Gem Parvus keyboard that had MIDI connectors.
It seemed that the best solution to record music was the Yamaha MDF2 diskette MIDI recorder. It looked easy to use – or so I thought.
Vale of Tears
I experimented recording some music and a few hymns. Very quickly I discovered the problem. To get a good recording I had to remember to do a number of things in exactly the right order. Clear the organ, press record, set the stops, play the piece, clear the stops, press stop. If I did this perfectly I had a good recording but still with a pause between the start of the track and when I actually played the first note. Most of the time I was not perfect. I pressed record AFTER setting the stops, I forgot to clear the stops either at the start or BEFORE I pressed stop. Sometimes I would complete a good performance to find that I had forgotten to press record at all. It was enough to reduce me to tears of frustration.
I also found out that the tempo I used playing a hymn in an empty church was very different to that used when playing with a full congregation. I realised that the ideal solution would be a system that only required me to press record once, at the start of a service, and it would then record everything and divide the recording up into individual pieces automatically. This would ensure the hymns were recorded at the correct tempo and that all the stop changes were saved correctly. It would also remove the gap between the start of the track and the first note. However, I could not find anything available that worked in this way.
My occupation at this time was as a Windows Developer for a large company and so I decided I would try writing something to make recording MIDI easier. Just something simple I could use. Unfortunately, there seemed to be no way to communicate with a MIDI adaptor. I approached a friend who was a technical programmer to see if he could help by creating a tool I could use to make a reliable connection. Once this was working I could then start writing my own program.
The first version was very basic. A few buttons on the screen to start and stop recording. The program saved all the MIDI messages and then, if I stopped playing for a few seconds, it wrote them to a file. It removed any pause at the start of a track by changing the time intervals so that all stop changes before the first note occurred immediately and the first note occurred about half a second later. I then improved it so that it would automatically add stop off messages at the end of the track. It was basic but it proved the concept worked. I could easily record an entire service with no action apart from pressing record before I started.
Tower of Babel
At this time I was still looking for a new organ for my church. I travelled round the country visiting various organ showrooms looking for a suitable instrument. I also started taking an interest in the MIDI implementation used by different manufacturers. It was at the showroom of Makin Organs in Oldham that I first began to realise the wide range of approaches that currently existed.
I knew that my Gem Parvus used one MIDI message for a stop ON and a different MIDI message for a stop OFF.
F0 35 14 06 F7 = ON
F0 35 1A 06 F7 = OFF
I quickly found that some instruments used the SAME code for a stop on and off.
CB 1A 00 = ON
CB 1A 00 = OFF
Even more surprising to me was the fact that some moving draw-stop instruments sent a long series of MIDI messages. There was one for every stop on the organ that was currently on even if you only changed one stop. This series was followed by an “End of List” MIDI message. This meant that when you turned a stop off – this list contained everything EXCEPT the stop you had just operated.
CB 22 00
CB 24 00
CB 7F 00 = ON
CB 22 00
CB 7F 00 = OFF
I was also aware that other companies used a single MIDI message to change several different stops. A combination piston to set many stops across several keyboards resulted in:
B1 10 19
B0 10 63 = ON
B1 10 00
B0 10 00 = OFF
In the case of others, one message could change the registration of the entire instrument.
F0 41 10 30 12 01 00 00 04 39 . . . . F7 = ON
F0 41 10 30 12 01 00 00 00 00 . . . . F7 = OFF
It seemed a confusing world of conflicting standards.
I cannot say the exact moment when I had the idea of developing what would become OrganAssist. It just seemed the natural thing to do. The fact that a recorded piece of music could only be played on one specific instrument seemed rather archaic and limiting.
Behind the Mask
In case you are interested, I will take a brief closer look at at these examples. It may be seem clear how a single stop can be changed by a unique MIDI message but the method used for multiple stops is slightly more obscure. Although the messages look very different, all manufacturers I have seen use a very similar method for multiple stops. To explain this I will NOT use the technical terms like Hexadecimal, Offset and Mask as I think the method can be illustrated clearly using simple arithmetic.
Note – In these illustrations, and later in discussing my own format, I have deliberately used numbers with only decimal digits so that the method is easier to understand if you think in terms of decimal numbers.
Using the example above – B0 10 63. The “B0 10” gives the identity of a group of 7 stops. The number 63 shows which of these 7 stops are on or off. How is that possible?
Imagine I give each of the 7 stops a number: 01, 02, 04, 08, 10, 20, 40. The number 63 tells me that the stops 01 + 02 + 20 + 40 (= 63) are on. However, it also tells me that the other stops in this group, 04 + 08 + 10, are off.
Again, in the last example above, the number 39 means that stops 01 + 08 + 10 + 20 are on and the rest of this group, 02 + 04 + 40, are off. In this case, since it is one long message, the identity of the group is determined by the position of the number within the message.
At the time I was discovering all this, my employment included writing software to convert documents and adapt them for printing on laser printers. This involved converting one data format into a totally different language. The document was held in a standard format but then was converted differently for each printer. Was this method possible for recorded performances?
I wondered if it was possible to store a musical recording in a “neutral” format and then use something like a Printer Driver to convert this into MIDI for a particular instrument. I realised that any conversion would require complex logic. An action that required a single MIDI message for one instrument may need to be converted to many MIDI messages on another. I did not believe there was some “magic” solution. What follows is just my own approach to the problem.
Keeping it simple
Organs are very complex instruments. What is the simplest way to store information about a performance? There are many features an organist uses – keys, stops, expression pedals, combination pistons, crescendos, memory capture systems etc. How do I store all this information. After much thought I decided that a performance consists of only 3 items.
Change in position of a note.
Change in position of a stop.
Change in position of an expression pedal.
Yes, there are all the other playing aids but essentially the performance can be reduced to a series of these 3 different actions. To ensure compatibility across all instruments I decided that these three would be the only things I record and that all changes would be relative. I would record the amount of movement of an expression pedal as a percentage of the total travel (either positive or negative). I would apply the same principal of relative movement to notes and stops – this proved to be very useful when dealing with multiple triggers as happens with couplers or crescendo pedals.
A Structured Approach
Although some companies use a standard numbering system for different stops, I realised that this was not enough to make translation possible. The system needed to cope when there was no exact match. How would the program select a similar but not identical sound?
A one-dimensional list of numbers or stops was not enough. I realised that the only way was to store the information in a more structured layout. I quickly found that to cope with all the different possibilities it would require a 4 dimensional array. This means that each stop is identified by 4 separate numbers – each number representing a specific characteristic of the stop. In my mind I called these characteristics Division, Pitch, Category, Character. The Division and Pitch are obvious. The Category could be Principal, Reed, Coupler (or even Note or Expression). The Character could be more detail about a stop or the coupled division for a Coupler.
Each of these items can be represented as a number. However, to make this system easier for other people to use when setting up an organ, these parameters are presented as a single long list of stops/couplers with buttons to select the division.
Using this system, the start of a piece could be stored in the following way:
01,08,03,05 Add Great, 8ft, Diapason, Large
02,16,04,02 Add Swell,16ft, Flute, Stopped
01,04,08,02 Add Great, 4ft, Coupler, Swell
02,37,01,40 Play Swell, 37, Note, Velocity
02,37,01,40 Release Swell, 37, Note, Velocity (stored as a negative number)
This system is very economical as all the information about a single action is represented as 4 numbers. These can be combined and stored as a single larger number that only requires 4 bytes of storage (which was very important in the computers of 1998). This number can be positive or negative indicating on / off or increase / decrease.
This approach made it possible to include a rather quirky but unique feature. During playback or editing it is possible to fast rewind a piece while listening to it. When running in reverse all that is necessary is to multiply all the numbers by minus 1. A note on becomes a note off, an increase in expression becomes a decrease, a stop on becomes a stop off. This is not very musical but it is a useful way to locate and repeat sections of a track.
Even storing the actions in this format was still not enough to enable a performance to be translated for use on a different instrument. What happens if a Large Diapason was recorded but only a Stopped Diapason is available? The only possible solution I could think of was to create a set of rules based on what I (and others I consulted) would choose to do. It seems obvious that if a recording indicates a flute was used, it would be best to use a flute during playback but …. consider the following situation:
A recording is made on an instrument which includes, in the 8ft stops on the Swell, a Diapason and an Open Flute. During a piece the registration changes are recorded (in order): Add Open Flute, Add Diapason, Remove Open Flute. This recording is to be played back on an instrument with ONLY two 8ft stops on the Swell – an Open Flute and a Salicional.
To start with, it seems obvious that the Open Flute would be used as it is an exact match. Then, when the registration is increased, there is no choice but to add the Salicional as a poor substitute for the Diapason. However, when the recording removes the Open Flute, it would probably be best to remove the Salicional instead, as the Open Flute is probably a better substitute for the Diapason.
This means that when the Open Flute was added an Open Flute was used but when it was removed the Salicional was used instead. Or, from the viewpoint of the Diapason, when it was added a Salicional was used but when the registration changed an Open Flute was substituted instead.
This difficult choice shows two things. It is impossible to match a single stop on one organ to a single stop on another instrument. Secondly – no stop change can be considered in isolation as it all depends on context.
For this reason I created some rules and priorities. Every time a stop change is made, these rules are run to recalculate the entire registration that would be best on the instrument being played. This is then compared with the current state of the organ and any stop changes that are necessary are issued. The advantage of using 4 different numbers to define a stop meant that these rules could be very general and expressed in mathematical terms. This should hopefully cope with any possible combination of stops that might arise in the future.
The Happy Couple
On most instruments the playback of notes is very easy. The notes are recorded and stored according to the keyboard they were played on. During playback these notes are played and the MIDI logic issues note messages on the correct channel for the organ being used.
However, a few instruments require more work. I have found this to be necessary with some tracker action organs equipped with MIDI, as well as a very few digital instruments. The problem is that they require note messages for all coupled keyboards. Sending a MIDI message to activate the coupler is not sufficient – the stop may activate but, without individual messages for all the extra notes, the sound does not change.
To deal with this I had to include a second category of coupler (Tracker) into the program. This triggers additional logic that automatically generates additional notes on coupled manuals during playback. To avoid unnecessary processing this logic is only engaged during playback of a piece that was recorded on a instrument with “normal” couplers. It is important that recording and playback on the same organ should remain un-altered This logic has to deal with both Unison and Octave, inter and intra manual couplers. I must admit that these do not “couple through”, as is the case on some instruments, but the result is much better than without any coupled notes.
Silence is NOT golden
One of the frequent problems I found when importing MIDI files, or playing them on a different instrument, was that the result was often silence. Either the notes were on the wrong MIDI channels or the stop changes were not recognised. For this reason I decided that I would avoid silence if at all possible. If there are notes or stop changes in a recording for a division that does not exist on the organ being played, they are moved another keyboard. They are moved between Choir and Swell as a first choice. If all else fails, they are moved to the Great.
The program will make every reasonable effort to find a replacement stop but, so as not to create alarm, it will NEVER replace your delicate Salicional with a Tuba Mirabilis!
One thing IS fixed – pieces will play back exactly as recorded on the same organ or exactly as edited and saved for another instrument.
Making it up “on the fly”
Not only does the choice of stops have to be made in real-time but also the MIDI messages have to be constructed as well. This is due to the fact, as we saw above, that some manufacturers use one MIDI message to affect several stops. If a stop is switched on or off at the console during playback then later MIDI messages, even for different stops, need to reflect this change.
The result is that the only solution was to make it all up “on the fly” – every stop change, every MIDI message is calculated in real-time.
Take, as an example, an organ with a Peterson system. This system uses a long list of stops that are arranged into groups. Each stop has a position within that group. Changing one stop on the organ will create a MIDI message with a block of data about the current state of all stops in that group. Using a piston to change many stops results in a longer MIDI message that contains multiple blocks of data, one block for each group of stops that was affected by the change.
Here is an theoretical illustration of one MIDI message (divided onto separate lines for clarity). Note that this uses the system, described above, of representing 7 stops as a 2 digit number.
F0 00 00 57 01 This is a header
10 This is a group of swell stops
02 60 00 03 4 x 7 stops of which 5 stops are on
30 Another group of swell stops
00 20 00 00 4 x 7 stops but only 1 stop is on
21 Now a group of great stops
40 05 27 41 4 x 7 stops of which 9 stops are on
F7 End of Message
Recording this information is easy. The incoming MIDI data is used to update all stops in each group to reflect the change. End of story. Playback, however, is much more complex.
When the “MIDI Driver” section of OrganAssist (for this manufacturer) receives a stop change, it cannot know if it is isolated or if it is the first one in a whole series that was triggered by a combination change. As it would be inefficient to issue a series of MIDI messages (one for every individual stop change) it notes the current time and waits for one tenth of a second. During this time it logs any further stop changes that are requested by the playback.
Once this time is up (or if a note or expression change occurs first) the program must calculate which stop groups are affected. For each stop group that has changed, it then finds all stops on the organ with the same group number and generates a block of data reflecting the current state of these stops. It repeats this process for every affected stop group. It then builds a MIDI message using a header, a data block for each stop group that has changed and, finally, an end of message code.
All of this has to occur in a fraction of a second!
The approach of generating the MIDI in real time also resolves the problem of editing stop changes in a recording. In some cases editing a single stop change in a MIDI recording is almost impossible. Many manufacturers use a MIDI implementation that includes many stops in one message or series of messages.
For manufacturers including Rodgers and Peterson, one message changes many stops. If you delete the MIDI message that was generated by a stop change it may either affect other stops that were changed at the same time or worse, when another stop is changed later in the piece it will change the stop you just edited. In the case of Rodgers, if you remove one message, every single MIDI message that follows will need to be changed because they contain the state of the stop you attempted to edit.
In the case of manufacturers that use the same MIDI message for ON and OFF, the result of removing a stop ON MIDI message is that the next message in the recording for this stop will switch it ON again rather than OFF.
Since OrganAssist edits the stored stop change itself, and the MIDI data is generated live during playback, the output will always correctly reflect the edit.
This complex logic would not be possible without the huge computing power that is now available in a average personal computer.
The single combination change I have illustrated involves re-evaluating the entire registration of the instrument multiple times to determine the action required. This is followed by the process of scanning the entire instrument multiple times to identify and collect the information needed to build the MIDI message.
It may seem wasteful to do so much processing. However, to ensure that a recorded performance can be played on any instrument, there is a complete separation of the playback logic, which translates and determines the registration, and the MIDI logic, which converts registration changes into MIDI messages.
This huge increase in computing power during the past decades has also made other things possible …
Long Live Hauptwerk!
Several years after I started work on OrganAssist, the first version of Hauptwerk became available in 2002. While I did make some attempts to provide support for this, it was not until early 2015 that I had the time to put in the substantial effort required.
Hauptwerk provided a unique challenge. Unlike every other organ system I had encountered, Hauptwerk requires OrganAssist to recognise multiple different MIDI messages for a single stop. The Great to Pedal stop on the St Annes organ can be activated in 5 ways: The stop itself, a thumb piston, a foot piston, the Crescendo and the FF thumb piston. Each of these creates a different MIDI sequence. Some are a single sequence, some are double and there are different formats using either NRPN or SYSEX MIDI messages. Programming a system to cope with all the different variations was an effort – but definitely worth it.
Hauptwerk lets me record and then play the same piece on many different organs. I can even download MIDI files from ContreBombarde and import these for playback on multiple instruments. Great fun!
A fresh bite at the Apple
What started out as a personal project some 20 years ago is still a work in progress. As time allows, I continue to develop OrganAssist.
In 2016, after more than a decade of requests, I finally released a beta test version for Apple MacOS. This was not technically possible before as OrganAssist depended on a program called Wine to run on MacOS. Unfortunately, the Wine MIDI implementation did not support SYSEX MIDI messages correctly. Even though the version released in December 2015 seemed the solution, there are still some technical problems. Hopefully these are now resolved with the Midi Helper utility that I have written to ensure that MIDI is delivered securely to the new version 3.0 of OrganAssist.
I am still adding manufacturers as people contact me with information. I find it intriguing to see the different ways that companies approach MIDI implementation. Even though the methods vary so much, I can often see a reason why a particular approach or format has been chosen.
Sometimes it seems that I have seen everything that organ MIDI has to offer … then a new format arrives in my inbox and my “Unexpectedly Long Journey” continues!