Rosegarden and Pipe Organ MIDI recording

If you want to use Rosegarden for recording and playback of Pipe Organ MIDI there are a couple of details you need to watch out for.
Rosegarden defaults to recording all channels to one track. You can record to separate tracks as follows:

• Double-click on the first track to rename it (e.g. Swell)
• Under Recording Filters select your MIDI device
• Select the channel (e.g. 1 for Swell - this varies with each system)
• Repeat with a new track for each manual/pedal

Now when you record you should see each manual on a separate track. If you get nothing then check that the Record Arm light (next to each track name) is on.

To get the playback to work correctly (and MIDI File Export) you need to configure the playback channel as well.

• Select the first track (Swell in our example)
• Under Playback Parameters select your MIDI device
• Under Instrument, select the instrument number that corresponds to the playback channel you want to use (e.g. Instrument #1 for Swell)
• Repeat for the other tracks

Need help with Pipe Organs and MIDI? Post me a question - I'll be happy to help.

Using Delegates and Events in C#

I wrote this mainly to remind myself what needs doing.
I don't often use delegates and it takes me too long to relearn it. What I wanted was a quick overview and reminders of how to do them. Here are my notes. I hope they help you too.

Delegates or Events?

Using Event doesn't support a return value but prevents subscribers to the event from affecting other subscribers (e.g. delegate=null) and from firing the event.

Events 

Pass parameters using a class derived from EventArgs
    public class FileNameEventArgs : EventArgs {
        public string FileName { get; set; }
        public FileNameEventArgs(string FileName) {
            this.FileName = FileName;
        }
    }
By using an event we don't need to declare the delegate, we can use EventHandler<T>
Declare the event in the source class
public event EventHandler<FileNameEventArgs> FileNameChanged;
Add a method for firing the delegate in the source class
    protected virtual void FileNameChange(string NewFileName) {
        EventHandler<FileNameEventArgs> handler = FileNameChanged;   //ensures our handler can't change between test for null and invoke.
        if (handler != null) {
            handler(this, new FileNameEventArgs(NewFileName));
        }
    }
In the client, write a handler for the event
    public void OnFileNameChange(object sender, FileNameEventArgs e) {
        Console.WriteLine(e.FileName);
    }
Subscribe to the event
    EventSourceClass.FileNameChanged += OnFileNameChange;

If there are no arguments to pass then we don't need FileNameEventArgs, we can simply use EventArgs, the default parameter type for EventHandler
public event EventHandler<FileNameEventArgs> FileNameChanged;
 becomes
public event EventHandler FileNameChanged;
and
EventHandler<FileNameEventArgs> handler = FileNameChanged;
if (handler != null) {
    handler(this, new FileNameEventArgs(NewFileName));
 becomes
EventHandler handler = FileNameChanged;
if (handler != null) {
    handler(this, new EventArgs());
and
public void OnFileNameChange(object sender, FileNameEventArgs e) {
 becomes
public void OnFileNameChange(object sender, EventArgs e) {

Delegates

We can use a delegate instead of an EventHandler by replacing the line:
public event EventHandler<FileNameEventArgs> FileNameChanged;
with a delegate...
Declare the delegate
public delegate void FileNameChangeDelegate(object sender, FileNameEventArgs e);
Instantiate a delegate
public event FileNameChangeDelegate FileNameChanged;
By using a delegate we lose the protection of EventHandler, but we are no longer restricted to the prototype void (object, EventArgs); e.g. we could have
public delegate int FileNameChangeDelegate(string NewFileName, bool LocalFile);

Adding file associations to VB.NET OneClick Applications

Adding file associations to VB.NET OneClick Applications

I struggled to find out how to do all of this. There are lots of suggestions on the net, but none that I found worked properly. You can't (or at least I couldn't figure out how to) add file associations through Explorer->Tools->Folder Options as the exe file doesn't launch like a normal windows app. To start with, it is hidden in "C:\Documents and Settings\UserName\Local Settings\Apps\2.0\....\...\..." (Replace the dots with random characters and guids!). Also, if I upgrade, the folder changes. When I tracked down the right exe and associated a file type with it I was getting reports that the file I double clicked isn't a valid executable. I knew that - I didn't want to execute it - I wanted to open it in my new editor!
I found plenty of articles on how to manually (programatically) edit the registry but all these had the same result as using Folder Options.

Anyway, I eventually located enough information to get this working the way I think it was intended, so I decided to blog it here.

I hope you find this helpful.

Add the icon file

I'm using Visual Studio 10 Express edition. This doesn't have an icon editor but I have an old copy of VC6 Pro that does, so I use this. I couldn't find a free editor but there are various free bmp to ico converters on the web, plus a ton of free icon files.
Add the icon to your project (Project->Add Existing Item).

Adding the file associations

Go to  Project Properties->Publish->Options->File Associations
Enter the file extension, the description (which will come up in explorer), a unique identifier (e.g. a guid), and select the icon for this file type.

This is good as far as it goes. If you publish/install the app it should set up the registry entries correctly, you will get the icon on your files and double clicking will open your program.

Opening the file

Having got this far I couldn't find out how you discover which file had been double clicked to launch the program. This was partly because I had migrated from VB6. I was trying to use the VB.Command() which retrieves the command line that launched the program, but this was always empty when the application had been installed. It worked fine with debug command line options. I found the correct way to find the file from a Click Once installation was to examine AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData, but you have to check it isn't empty first or ActivationData.Count will throw an exception.
Here is my form load code:

    Private Sub Form1_Load(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs) Handles MyBase.Load
        Dim FileName As String

        FileName = ""
        If Not String.IsNullOrEmpty(VB.Command()) Then
            'search for any extra command line parameters
            FileName = VB.Command()
        Else
            If Not IsNothing(AppDomain.CurrentDomain.SetupInformation.ActivationArguments) Then
                If Not IsNothing(AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData) Then
                    If Not IsNothing(AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData.Count) Then
                        For i As Integer = 0 To AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData.Count - 1
                            'search for any extra command line parameters
                            FileName = AppDomain.CurrentDomain.SetupInformation.ActivationArguments.ActivationData(i)
                        Next i
                    End If
                End If
            End If
        End If

        Me.Show()

        initalise() ' initialise system globals

        'get command line file name and open it if present
        If (FileName <> "") Then
            LoadFile(FileName)
        Else
            Me.FileNew()
        End If
    End Sub


n.b. When using ClickOnce you will find it sets the ClickOnce Security Settings every time you publish your program. Then, the next time you try to debug with any command line options (Project Properties->Debug->Command line arguments) it warns you that "command line arguments will not be passed to the executable". You can turn this off by clicking Project Properties->Security; Select partial trust; click on Advanced and turn off "Debug this application with the selected permissions set"; OK; Finally, select full trust.

Playing MIDI files on a Pipe Organ

We have the technology, we just don't have an organist.

Many churches struggle to find an organist, and with such a wonderful instrument at their disposal it is wrong to let the pipe organ languish. Many pipe organs are being fitted with MIDI interfaces which allow recording, playback and tonal expansion. With the right application of this technology it is possible to use the pipe organ to accompany worship even when the organist isn't available.

There are drawbacks. Most MIDI files are scanned from score and sound robotic when played and only an organist is capable of compensating for a congregation that gets out of time. But what if you don't have an organist but you do have the technology. Getting it all working with a suitable library is no mean feat, but it will keep the organ in use until an organist can be found.

If you can get an organist to record the hymns for you then the recordings can include an introduction, correct registration (stops) etc. Building a comprehensive library will be a time consuming task though and you have to consider licensing issues as the organist is entitled to royalties whenever you use his recordings. When making recordings ensure that all of the stops are off and the expression is closed before the recording is started.

If you don't have the resources to make your own recordings then the alternative is to use MIDI files. I wish I could just point you to the right web-site to download all the hymns & songs you need in just the right format, but, alas, it is not that easy. Most music publishers don't provide MIDI files because they lack copyright control. MIDI files are small and easy to copy and with readily available software you can turn them into sheet music and print out illegal copies.

You will need to search the internet for the files. I'd suggest looking for particular hymns to start with and see which ones are on sites with good collections. Check the website Ts&Cs to make sure the MIDI files are in the public domain. You may also need to check with the music publishers that the use of such material is legitimate or that any royalties/license fees are paid. Here are some useful links:
http://www.midi.org/newsviews/usco_pr.shtml
http://www.ccli.co.uk/
http://www.prsformusic.com/Pages/default.aspx

Once you have the MIDI files you will need to check the channels used. With a Solid State MultiSystem the manuals (keyboards) are numbered from the top down

2 Manual Console	3 Manual Console
Channel 1 Swell Notes	Channel 1 Swell Notes
Channel 2 Great Notes	Channel 2 Great Notes
Channel 3 Pedal Notes	Channel 3 Choir Notes
	Channel 4 Pedal Notes

Channel 1 Master Volume will control the Swell Box. Note that the lowest volume (0) will not be silent.

Most MIDI files for single instruments will use channel 1, but MIDI supports 16 channels and a creative MIDI file arranger might have used multiple channels for different tones. Initially you will probably want to play the accompaniment part of the hymn on the Swell with the melody on the Great. If the source MIDI file doesn't include a Pedal or bass part then you can often extract the bottom note of the accompaniment to use on the Pedal channel. If the MIDI file only uses one channel then start with this on the Swell channel. Most simple MIDI editors should allow you to do these things.

Michael Lawrence's "A Short Primer on Hymn Playing" includes useful information to consider when preparing MIDI files for congregational use. Especially useful are paragraphs 5 & 6 on registration and introductions.

Registration

Getting the right combination of stops will be different for every organ. If you can get an organist to advise you it is worth spending some time with them, taking notes. Read Keith Simons' "The Easy Guide to Playing a Pipe Organ (for church services)" as this has lots of useful information on registration. At a minimum you will want three registrations: First verse; Penultimate verse; Last verse.

If you play a MIDI file through the organ you probably won’t hear anything. Unlike most electronic instruments an organ doesn’t have a default sound. You will need to draw (turn on) a stop (or stops) for the particular division (MIDI channel - Swell, Great etc.).

Getting the correct registration during playback

Options:
1) Turn the stops on by hand.
2) Turn the stops on using a piston (a pipe organ equivalent of a preset).
3) Turn the stops on using MIDI

Turning the stops on by hand is pretty easy if you don’t want it to change during playback. If you want changes then you will need to move the stops in a timely fashion at the correct point in the music. You will probably need some practice and possibly some assistance.

Pistons are push buttons mounted below the keys. They are usually available as divisional (Swell, Great etc.) mounted below the middle of the relevant keyboard; and Generals, usually mounted below the keys toward the left. Depending on the age of the system these may be fixed, controlled with switches (a "setter-board"), settable (there will be a set piston, usually below the left of the bottom keyboard) or settable and scopeable (with a scope piston adjacent to the set piston). There will often be a general cancel piston to the bottom right which will turn all of the stops off.

If the pistons are fixed or have a setter-board then they will probably be set up for accompanying hymns. Choose the ones that sound right.

If the pistons are settable then check with the organist (I know, why would you be reading this if you have an organist) before changing them. Many systems have multiple levels/channels and one could be assigned for use with MIDI playback. The pistons are usually set by turning on the stops, holding in Set and pressing the piston.

Scopeable pistons are settable but can also be adjusted for which stops they affect (you can control which stops go on, which go off and which remain undisturbed).

Once the pistons are set up the registration can be changed by pressing the appropriate piston.

Turning the stops on with MIDI can be accomplished a number of ways. Unfortunately MIDI wasn't designed with multi-timbral instruments in mind (organs are multi-timbral in the sense that there is more than one sound available simultaneously on each keyboard). Different Pipe Organ MIDI systems use different methods to control the multi-timbral facilities of the organ.

The system I am going to describe is that used by Solid State's MultiSystem. This is a networked Pipe Organ control system which supports MIDI (through MFM) and integrated capture (piston) system (CFM). The principles can be applied to other makes of equipment but you will need to refer to the documentation for the exact implementation.

There are two ways to turn the stops on using MIDI. One is to control each stop individually, the other is to make use of the piston system.

Controlling the stops individually

On MultiSystem, Stops are turned on and off using System Exclusive messages.

The Hex values for Stop ON messages are:
F0, 2B, 01, 01, 23, xx, yy, 00, F7

The Hex values for Stop OFF messages are:
F0, 2B, 01, 01, 22, xx, yy, 00, F7

The xx, yy values hold the stop index (0-2047). These vary from system to system. These are available from Solid State or you can observe the MIDI OUT2 whilst turning stops on and off.

You will need a MIDI editor which supports arbitrary SysEx messages. Locate the position in the file where the registration needs to change and insert the required SysEx messages at that point. You will need to ensure that a corresponding Off message is sent for every on message or you will end up with stops stuck on in the organ until you turn the organ off.

Controlling the registration using MIDI controlled pistons

If you have a CFM piston system then you can set the pistons at the console and trigger these pistons by sending the correct MIDI SysEx codes to the pipe organ.

The Hex values for Piston messages are:
F0, 2B, 01, 01, 27, xx, yy, 00, F7

Where xx, yy is the piston index. Again, these vary from system to system. They are available from Solid State.

You can use a MIDI editor to insert these messages. This method is simpler as you don’t need to keep track of every stop transition.

Simplifying the MIDI editing

You can simplify the MIDI editing further by using a MIDI translation utility. For example "Bome's Midi Translator" which allows you to translate MIDI Presets into Pipe Organ SysEx messages. With this in place you can use MIDI Presets to control the organ. MIDI Presets are fully supported by MIDI sequencer software and are much easier to edit (you don’t have to edit hex messages). MIDI Presets are channel specific and I would recommend using channel 1 all the time.



I hope this proves helpful to you.
Please feel free to leave comments, but please don't use this as a forum for debating the morality of using MIDI instead of an organist.