midi to pipe organ conversion

MIDIfication
1

Part of this discussion has already been written in the diode matrix discussion, but maybe this is a better place for my and your ideas. Or wiki, but I doesn’t seem to work right now.

Here is my idea to midi conversion to pipe organ.

About: Organ pipes controlled with midfied console.

When I came to this website and read about the MIDIO128 I also thought it can be used to control  pipes and make a unit organ. This means one rank of pipes use different stops, with different  transpose (1 octave, 2 octave, - 1 0ctave, 2 1/2 octave etc.)

My idea is this:

We have input:

1,2 or 3 manuals + pedal          realtime midi input from different channels: note on type.

Stops pulled input:            This contains: division (what manual)

                       What Rank (Prestant, Trompet, Flute)

                       What Height 16’, 8’ , 4’ etc (8’ = 0 transpoze, 16’ = 1 octave                        down, 4’ is one octave up. ’ stand for feet. The longest pipe on ‘piano pitch’ C is 8 feet. 16’ = twice as long = twice as low = one octave down.)

For this we can use different midiboxes or the one with a huge matrix input in development right  now.

We have output:

Up to 16 ranks. With 128 or less pipes. These pipes can be controlled by midimesseges, note  onoff, on the right channel. This means noteon messages received on channel 1 will be used to  open or close pipes on rank 1 (Prestant for example), messages on channel 2 will control rank 2  (Flute). etc. For this we can use a MIDIO128 for each Rank/Channel, which controls the ranks.

Next step: processing.

I don’t know C and just have little experience with Java, but here is some quick code.

We an use a midiprocessor for this purpose. We get a lot of cores in this way, but I think that  works fastest and is easiest to explain for now. Later we can bring it all to less midiboxes.

in the midi processor we need some matrixes: SP1, SP2, SP3, SPP (stopspulled1, stopspulled2,  stopspulled3, stopspulledPedal.

The best thing is to put thes in to a main matrix SP= {SP1,SP2,SP3,SPP}

In this matrix we save what stops are pulled.

SP* look like these:

                 

                 

               Rank / Channel

     

               Transpoze      0 1 2 3 4 etc. 15

Height  16’       -12         0 1 0 0 0  0    0

             8’        0                   0 0 1 0 0  0    0

             4’        +12        1 0 1 0 0  0    0

             2 2/3’  +19        0 0 0 0 0  0    0

             2’        +24        1 0 0 0 0  0    0

             1 3/5’  +28        0 0 0 0 0  0    0

             1 1/3’  +31        0 0 0 0 0  0    0

             1’        +36        0 1 0 0 0  0    0      

(looks not to good, but I don’t know how to get it better)

This is a 8*17 matrix. This makes SP a 4*8*17 matrix. But different sizes can be made according  to the pipes and ranks that are available. A normal church organ would only use the 8’ height.

Stops pulled are: 4’ and 2’ at channel 0, 16’ at channel 1, 8’ and 4’ at channel 2.

First consider a noteon event:

9n xx vv            n = channel xx=pitch

First we check the channel.

channel=n;

Originalpitch=xx;      (Save original pitch because messages will contain transposed pitch)

volume=vv;            (either 0 or normal noteon value)

For r=1;SP[channel,length]      ; for all rows.      We first process one row and send the pitch

                       ;belonging to that channel to all ranks(channels) for which the

                       ;stop is pulled.

pitch = originalpitch + SP[channel,r,0]            ;Change pitch.

For k=1;SP[channel,r,length]      ; for all kolomns.

if SP[1,r,k]=1                  ; check if stop is pulled/ if note has to be sent on this  channel.

send 9k      pitch volume            ;send corresponding noteon message with right pitch to right  channel

End ;for k=…

End ;for r=…

How to fill SP.

When a message is received that a stop is pulled/unpulled, the corresponding matrixentry has to  be set/unset.

The best thing to do is, i think contain this all in the stop message:

Stop message

Yn pp vv

Y= A,B,C whatever is not used. We may need to, for on/off.

n= channel corresponding to pedal, manual I etc.

pp = pitch,      /determines height

vv= volume.      /determines rank

If … Stop on message is received.

Division=n;

Height=pp;

Rank=vv;

SP[Division,Height,Rank]=1.

If … Stop off message is received.

Division=n;

Height=pp;

Rank=vv;

SP[Division,Height,Rank]=0.

Coupling:

Maybe this can de done in the midibox, the manuals are coupled to: send midibyte on two  channels.

Problems to be solved:

Noteoff.

This could be a problem when using say 8’ and 4’ on one channel. Say you press c1 and c2  together, but release c2 first. Then you get a noteof message for c2 on your rank, but it should  be one, because the 4’ at c1 adresses c2 also. I will think about this. Any suggestions?

For a normal organ only working with 8’ it’s no problem, except if the manuals are coupled.

Stopoff.

If you put a stop off, you cannot turn the pipes off anymore, because apropriate midi messages  will not be send. This means we need a noteoff on that channel, or for everynote  pressed on  that channel and height. This is another difficulty that will have to be overcome, or an  imperfecty we have to live with.

What we need, except for the pipes I can’t afford yet :-(, is a program in C to process the input and manage the output. The SP matrix can be different for everybody using this,  but it will be no problem to adjusting this in the main code. I am willing to write this program in the future, for the midiprocessor, although I don’t now C yet. Is there anyone who need this program in the near future? To check I luckily don’t need all the pipes :slight_smile:

Yours

Rednas

2

What you propose is possible but very ambitious.  If you want to do that, I think it will be better to learn PIC assembler than C.

Since you can’t afford the pipes right now, have you tried any of the virtual organs? Hauptwerk http://www.hauptwerk.co.uk/ is good for classical organs. My program, Miditzer http://www.miditheatreorgan.com/, is a theatre organ, highly unified in the way you propose.  jOrgan http://www.meiers.net/sven/ is written in Java. Not only will these give you some immediate gratification, they will give you a chance to learn more about how organs work.

There are commercial solutions for connecting consoles to pipes. Unless you value your time at nothing, you probably will come out ahead using a commercial solution. Look at Opus Two http://207.236.55.58/users/opustwo/index.html for example.

3

It is amibitious indeed, but I thought this is a bit what you wanted too. And there are some problems to overcome as I told already, but if that is done it should work.

PIC assembler may indeed be easier/better than C. I don’t have discovered how all of MIOS work, so I don’t know what to use yet. I thought of altering the MIDIprocessor program for this purpose, and use whatever it is using.

I use jOrgan at the moment. I use two keyboard and just bought a pedalboard from an organ builder. If connected the reedcontacts already, but am waiting for a midiconnection board. Monday I discovered this site and it will be usefull for the rest of the organ console I think. Especially if the matrix input works fine. In this way I can practise warm and dry at home at all organ literature whenever I have spare time. I can play at some organs in the neighbourhood too, but not always, and I have to go there and it can be cold in the winter.

It would be nice to have a real organ at home. With real pipes. With the console I’m building I can adres them. And in this way I can connect and buy one rank at a time. Time should not be the problem yet.

I will look into opus two. What was your idea at controlling pipes with midi exactly?

yours

Rednas

4

My idea is that I don’t want pipes at home. The care and feeding of pipes is just more than I can handle in my house. I do all the things you talked about in a C++ program running on a PC. Since I use PC hardware, SoundBlaster, to generate the sound it doesn’t matter to me whether the relay function is done on the PC or in the MIDIbox. Putting the relay in a PC rather than a MIDIbox means I don’t need to think so hard about being efficient. I only need MIDIbox to convert console keyswitch contacts to MIDI.

Are you planning to use the switch matrix in your project? If so, I better get busy and release something for that project.

5

Are you planning to use the switch matrix in your project? If so, I better get busy and release something for that project.

I am. I ordered parts this week, so next week I can put stuff together. Then I must also build the drawknops with it’s contacts and some preset buttons etc. Than  Crescendo pedals and maybe manuals instead of synthesizers. But to use all this I really like the matrix. I don’t know how much buttons it will be, but I think I can also test some part of the program before it will be officially bug free and released.

6

Since I use PC hardware, SoundBlaster, to generate the sound it doesn’t matter to me whether the relay function is done on the PC or in the MIDIbox.

I also don’t care yet. jOrgan works fine. But maybe later it will be better without computer and with pipes.

7

I am [using switch matrix]. I ordered parts this week, so next week I can put stuff together. Then I must also build the drawknops with it’s contacts and some preset buttons etc. Than  Crescendo pedals and maybe manuals instead of synthesizers. But to use all this I really like the matrix. I don’t know how much buttons it will be, but I think I can also test some part of the program before it will be officially bug free and released.

Is your plan to get the MIDIbox working first and then connect the console to the MIDIbox incrementally? That is the approach I am using because once the MIDIbox works it becomes a fast way to check the console wiring. You can temporarily configure stops to send Note On/Off and hear whether things are working as you go.

Will your MIDIbox be a CORE, DIN, and DOUT? If you have a full DIN and DOUT it is easy to change the dimensions of the matrix by changing the software. I hope that changing the software will be easy too. ::slight_smile:

Have you made any decisions about what matrix dimensions you will use? I chose to make my DIN 32 bits wide to allow large groups of switches to share a common bus. I have a wired pipe organ console that I am working on and it has 122 key contacts on a common bus. I’ll have to divide that into 4 busses. I will use 16 DOUT bits to select busses to give me 512 inputs. If I made the matrix 24x24 I could get 576 inputs with the same number of wires but I would have to divide my keyboards to have 6 busses.

Right now, I have an 8x8 matrix working. If you want something other than 16x32 I should do that next as it sounds like you are closer to wiring something up than I am.

So far I have half of my diode matrix built and it will be at least another month before that is finished. It will probably be another month after that to assemble the whole MIDIbox which will be a panel that goes in the back of the console to receive all the existing console wires, none of which is color coded or identified. Then I start tracing hundreds of wires to connect the console to the MIDIbox.

8

Good idea to test the wiring with the midibox. For my pedal I used a self fabricated testset with one led and two batteries. It works fine, but I had only thirty contacts. The pedal uses a common bus for 4. So that could easily be tested for 8 or more.

Manuals:

I don’t have these yet. For the pedal I made wiring. I planned to use a manual from an old organ. This would have one common bus I think. No second touch for me :-). I think this is a common thing to do. It is not to much trouble to cut it in two or three, if you don’t use the organ anymore. But I think cutting in two will be best. So 32 is a good number. I can also construct wiring for existing manuals. I have some here from old harmoniums, but without springs, so I have to fix that too. Or I’ll take a look on the internet if someone has some for sale.

I ordered 2 Cores, 1 Dout, 2 Din, 1 Ain and a JDM. This would be enough to experiment with right know.

I’ve made plans for a common organconsole, for three manuals and pedal and planned 4*10 stops on both sides of my console. But maybe these dimensions will change. Maybe this will change for a unit organ. But that can also be done later.

I think 16x32 is fine. If not I can also redirect the wiring for this project. I will think about it when the console is ready.

9

I forgot to tell:

The preset buttons wil not be to hard to make. When they are ready I can easily test all combinations for the 16x32 matrix. So if you need some help i’m here for you.

10

>

>  We have output: Up to 16 ranks.

>

Why limit yourself to 16 ranks?

I

11

John, nice organ console. I guess that pipes are working too, with MIDIO128 or something? What is your setup? Pipes and hauptwerk or something?

You’re right. Limitation to 16 ranks is not necessary but easy. In this way you use the 16 midi noteon channels for noteon messages. You could use more filters, or extra channels like 5n. Another possibility is sending messages for two ranks of 64 pipes on one channel, using all 128 notes. But this is an extra difficulty. 16 ranks can be enough for a regular organ. Remember 16 ranks for all manuals, since it is midi driven. If you have a unit organ, every rank can have multiple stops like 8’, 4’ 2’ etc. So 16 ranks mean a few dozen stops on each manual. This must be enough for the regular home organ.

For software it is not that much. But with the soundblaster soundfonts, you’re limited by the polyfony of 64 for each card. That’s why I have 3 pluged in right now :-). Thanks to kxproject. (Link can be found ot jOrgan website). Polyfony 64 means 8 notes with 8 stops, so I can have 8 notes with 24 stops. And if this isn’t enough, I’ll buy another card :slight_smile:

But limitation is not necessary. We have to remember that there is not too much latency through the midifilter though.

12

I came up with a better idea instead of the matrix. To use  ordinary variables and use the bits as data. For each height we need two or three bytes. This depends on wether we will you the first bit as a register. In normal midi messages this one is always zero. If we stick to normal midimessages we need three to cover 16 bits.

So for instance we have for 8’ 0x26 0x63 0xC0

In bits: 00100101 00100011 11000000

Forget the bits that don’t count:

0100101 0100011 11

or better to read:

0100 1010 1000 1111

This means midi messages at this channel will be forwarded to output channels 2,5,7,9,13,14,15,16

In the function the bits can be read . If 1 a midi message will be sent, if not, read the next bit and raise the midichannel.

For the stops we need an apropriate midi message.

For instance

;;  PROC Received Bn: called on a Controller Event

;;  In:      MIDI_LASTEVENT0: Bn, n = midi channel

;;      MIDI_LASTEVENT1: CC number

;;      MIDI_LASTEVENT2: CC value

The strong point of this method is: we can use the xor functions to toggle stops. Set and unset is not supported in this way. That would be another routine. And all stops off message will be implemented.

1000 0000 0000 0000

Will toggle channel 1 when xor is used with the bytes in memory.

0100 0000 0000 0000

Will toggle channel 2

0010 0000 0000 0000

Will toggle channel 3

We had

0100 1010 1000 1111

Now we toggle channel 2 so we have:

0100 1010 1000 1111

xor

0100 0000 0000 0000

Will give

0000 1010 1000 1111

Pull channel 1 will give

0000 1010 1000 1111

xor

1000 0000 0000 0000

=

1000 1010 1000 1111

Another advantage:

Presets can be implemented directly.

First send an all stops off message. (To be implemented)

Then send a bunch of messages for each channel and each height

like send 1010 0000 1000 0000 for 8’

and 0100 0001 0010 0000 for 4’

etc.

To set 8’ on channels 1, 3 and 9

4’  on channels 2, 8 and 11

I’m trying to program this for PIC16F877 in the MIDfilter/processor. Jim Henry, you can wait for this or use a computer program. Maybe both is als a good idea. I hope this helps you too. It can make a standard language you were looking for I think. Any recommendation for codes to use, two or three bytes or other stuff?

I must find out how to make variables, but I think it will be somewhere in the help file of MPLAB.

13

So for instance we have for 8’ 0x26 0x63 0xB0

In bits: 00100101 00100011 11000000

IMHO 0x26 0x63 0xB0 equals, in bits:

00100110 01100011 10110000

14

Thnx. You’re right. It’s a bit new to me, Hex. I will edit my message for this.

15

I’ve been busy, and have code like this so far. IT IS NOT FOR THE PIC18… but for the PIC16…

First implement variables:

I did this in main.*

Stop variables consist of three bytes.

Cblock 0x20

     Pitch

     Channel

     Velocity

     Ranks

     StopsP16:3

     StopsP1023:3

     StopsP8:3

     StopsP4:3

     StopsP223:3

     StopsP2:3

     StopsI16:3

     StopsI8:3

     StopsI513

           …

ENDC

To route incoming messages according to manual/channel:

PROC_Received9n

     movf      MIDI_LASTEVENT0, W      ;; get event byte #0

     xorlw      0x90                  ;; compare channel with 0

     skpz                              ;; skip next command if equal

     goto      PROC_PEDAL      

;; for all manuals

This is used to send messages:

PROC_SEND                              ;;used to send output midimessages to ‘pipes’

     movf      channel, W

     call      MIDI_SendByte

     movf      pitch, W

     call      MIDI_SendByte

     movf      velocity, W

     call      MIDI_SendByte

return

Velocity is original velocity.

For each manual there is a routine to redirect the messages according to the values of the height and ranks, and adjust channel and pitch to that.

PROC_PEDAL

;;===============================================================================

;;      this will handel messages coming from PEDAL (ch0)

;;      In:      MIDI_LASTEVENT0: 9n, n = midi channel

;;      MIDI_LASTEVENT1: note number

;;      MIDI_LASTEVENT2: velocity

     movlw      0x90            ;;midimessage for channel -> W

     movwf      Channel            ;;load channel 0 in channel

     movf      MIDI_LASTEVENT1, W

     movwf      Pitch            ;; move note number to pitch

     movf      MIDI_LASTEVENT2, W

     movwf      Velocity      ;;save velocity message in velocity

;;-----------------------------------------------------------------------------

;;      process all stops for Pedal

;;      StopsP16:3

;;      StopsP1023:3

;;      StopsP8:3

;;      StopsP513:3

;;      StopsP4:3

;;      StopsP223:3

;;      StopsP2:3

;;------------------------------------------------------------------------------

;;      StopsP16:3

     ;; adjust pitch

     movlw      0x0C      ;;12

     subwf      pitch,1      ;;pitch-W->pitch

     ;;check if midibit has to be sent on channel. if it does, do so immidiately wth PROC_SEND

     BTFSC      StopsP16,1                  ;; if this bit is 1

     GOTO      PROC_SEND                  ;; send message at channel 0

     INCF      channel                        ;; increment channel

     BTFSC      StopsP16,2                  ;; if this bit is 1

     GOTO      PROC_SEND                  ;; send message at channel 1

     INCF      channel                        ;; increment channel

     BTFSC      StopsP16,3                  ;; if this bit is 1

     GOTO      PROC_SEND                  ;; send message at channel 2

     INCF      channel                        ;; increment channel

     BTFSC      StopsP16,4                  ;; etc

     GOTO      PROC_SEND                  

     INCF      channel                                    

     BTFSC      StopsP16,5

     GOTO      PROC_SEND                  

      …

     BTFSC      StopsP16+1,3

     GOTO      PROC_SEND                  

     INCF      channel

      …

            BTFSC      StopsP16+2,2

     GOTO      PROC_SEND                  

     INCF      channel

             

This for all stops.

Next step, pulling stops.

;; ==========================================================================

;;      THIS WILL IMPLEMENT PULLING STOPS

;;      It assumes same message for pull or withdraw

;;      The message contains three bits with it’s own function.

;;      n, midi channel: What midichannel does the message belong to.

;;      n%4 = midi inputchannel notedata

;;  midi channel modulo 4 = midi inputchannel notedata

;;

;;      Channels 0 to 11 are used.

;;      0,4,8: channel 0/ pedal

;;      1,5,9: channel 1/ manual I

;;      2,6,10 channel 2/ manual II

;;      3,7,11 channel 3/ manual III

;;      Note number:

;;      Defines tranposition

;;      Not all are used.

;;      Transposition = notenumber-24  (36)

;;      note number      tranpose      in feet

;;      0                                          64’

;;      12                                          32’

;;      24                                          16’

;;      31                                          10 2/3’

;;      36                                          8’

;;      43                                          5 1/3’

;;      48                                          4’

etc.

goto right manual:

PROC_ReceivedAn

;;check to which manual

;;1010rrmm

;;two bits of rr define ranks (byte 0, 1 or 2)

;;two bits of mm define manual (0,1,2 or 3)

     movf      MIDI_LASTEVENT0, W            

     iorlw      0xFC                              ;; 1010rrmm ior 11111100 = 111111mm

                                                     ;; 1111 11mm xor 1111 11nn = 0000 00pp

     xorlw      0xFC                              ;; manual = 0      -> W = 0

     skpnz      

     goto      PROC_PEDAL

                                                     ;; manual != 0 -> W = 0000 00mm

     xorlw      0x02                              ;; manual = 2  -> W = 0

     skpnz

     goto      PROC_MANUALII                  

goto right rank

PROC_STOPSP

;;      a stop is pulled for pedal

;;      determine which rank

;;MIDI_LASTEVENT0 = 1010rrmm

;;two bits of rr define ranks (byte 1, 2 or 3)

;;two bits of mm define manual (0,1,2 or 3)

     clrf      ranks

     incf      ranks                        ;;                                                                              0:1      1:1      2:1

     BTFSC      MIDI_LASTEVENT0, 4      ;;Check 5th bit of MIDI_LASTEVENT0.

     goto      PROC_STOPSPR3            ;; only if it is 2                                                      0:1      1:1      2:2

     

     BTFSC      MIDI_LASTEVENT0, 5      ;;Check 6th bit of MIDI_LASTEVENT0.

     goto      PROC_STOPSPR2                        ;; only if this is one                              

     

     goto      PROC_STOPSPR1                        ;;                                                                              0:0      1:1      2:1                                    

     return

PROC_STOPSPR1

;;      Stop processor Rank 1

     

;;      First data byte is used. We have the right manual and the right rank number.

;;      Move to second databyte.

;;

;;      Note number:

;;      Defines tranposition

;;      Not all are used.

;;      Transposition = notenumber-24  (36)

;;      note number                        in feet

;;      24      0001 1000      0x18            16’

;;      31      0001 1111      0x1F            10 2/3’

;;      36      0010 0100      0x24            8’

;;      48      0011 0000      0x30            4’

;;      55      0011 0111      0x37            2 2/3’

;;      60      0011 1100      0x3C            2

;;      StopsP16:3

;;      StopsP1023:3

;;      StopsP8:3

;;      StopsP4:3

;;      StopsP223:3

;;      StopsP2:3                                          

     movf      MIDI_LASTEVENT2, W

     xorwf      StopsP16                      ;; pull stop in memory.

     movf      MIDI_LASTEVENT1, W

     xorlw      0x18                        ;; w= 0 if 16’

     skpnz

     return

;; apparently stop was pulled in memory. Leave this routine

     movf      MIDI_LASTEVENT2, W

     xorwf      StopsP16         ;; unpull stop 16’

     xorwf      StopsP1023      ;; pull stop 10 2/3 ’

     movf      MIDI_LASTEVENT1, W      

     xorlw      0x1F                        ;; w= 0 if 10 2/3’

     skpnz

     return

     movf      MIDI_LASTEVENT2, W

     xorwf      StopsP1023

     xorwf      StopsP8      

etc.

Things to do: Cancel all stops for one height (in cas of hangers. / all notesoff

Implement presets. I said earlier this will be easy, but not with the routine used now, because after one pull is detected, it leaves the routine.

It’s an awfull lot of text, but thanks to copy, paste and replace the workload is much less  ;D

16

Hey Rednas,

There have been over 3000 replys on this thread since I asked the first question, and it has been some time since I participated.

However, I have a working console, 2 manual and pedal board with working stops and swell shoe, and have been very successful running jorgan, including version 2.  My original concept was to utilize midi to construct a pipe organ, and I am still on that course. Presently I have acquired a blower capable of 5 ranks or so, a 16’ subbase rank, 4’ diapason rank and part of a 2’ salicional. I have also amassed a store of wicks and reisner magnet valves. Most of this I scrounged, and I am still in the hunt.

I presently have two midio128 cores working in the keyboard encoder area with 4 DINS on one and 3DINs on the other. I received today another DIN to add to the second core so that I can add pistons and couplers.

My console is a Moller artiste which I had to partially re-wire.

I am in the process of working out the overall design for the additional cores and DOUTS to drive the pallet magnets.

I do want to retain the ability to use Miditizer, jorgan or Hauptwerk.  The approach I am taking is more straight forward, using the basics of mios and the midio128 without custom programming, of which i know little. therefore, I am very interested in your work with MIOS, in particular for stops, pistons, memory and couplers.  My organ must play without a computer attached.

Send me your email address and I will share  what I have done with you.

All of this has been done using other pic processors, boards, etc., by several including petrov, so I am sure that it can also be done using midibox technology and programming.

I suggest you read back through the thread on this subject. There is a wealth of good information including the tough of the master, Thorsten Klose.

Regards,

Johnc

17

Hi Rednas,

I am from Italy, and I am in constructing my real pipe organ, too.  the real pipes are real pipes!

Have you solved your two problem, wrote in your first post?

–> Noteoff.

This could be a problem when using say 8’ and 4’ on one channel. Say you press c1 and c2  together, but release c2 first. Then you get a noteof message for c2 on your rank, but it should  be one, because the 4’ at c1 adresses c2 also.

–> Stopoff.

If you put a stop off, you cannot turn the pipes off anymore, because apropriate midi messages  will not be send. This means we need a noteoff on that channel, or for everynote  pressed on  that channel and height.

I want to use a midi0128 for each rank of pipes (or at least two), that keep in memory what stops and what solenoid must play for every midi channel (keyboards and pedalboard). I think this solution is easy. I have channel 1-3 for keyboards and channel 0 for the pedals and the decoders midi0128 all connected on cascade metod by midi throw.

But I had not think to your two problems… If you have solved them let me know!.

Thank a lot,

Gu.

18

Thanx, Per … this is exactly the kind of application

I was seeking.

This is how I have configured my present working model

Baldwin/MidiTzer hybrid, dedicating a particular

keyboard solely to the Roland Sound Canvas, and why I

refer to it as my “Antiphonal/enChamade” manual.

documented at

This keyboard is not accessible from any other

keyboard or intramanual piston, and that’s OK with me.

It is definitely not a floating division out there,

and most designers would think it kinda klutzy, but it

works for me.

I think of this keyboard as a separate organ that

shares a manual keyboard within the real estate of the

console. I must simply select a Sound Canvas MIDI

instrument for it to connect to (piano, carillon,

brass trio, whatever) from the Sound Canvas itself

(that’s why I have the face plate of it incorporated

into my Baldwin console design for easy access).

Why could not a particular manual send MIDI commands

to a switchbox to actuate an horizontal wall-mounted

rank of enChamade pipes or actuate grandma’s pump

organ across the room, or play a melody on vibes (like

at Lorin’s studio), or actuate a simple swell chest

with particular pipes within it … that would serve

my need (as long as they were in tune with the

MidiTzer keyboards, heh!).

It is an “either / or,” not a “both / and” situation from

a designated MIDI keyboard that resides within the

console, unconnected from the other keyboards that

are unified with each other.

Do you get my drift?

I mentioned I am working from a foam coreboard frame

console mockup of my gutted Wurli, using labeled

tongue depressor tabs and MIDI keyboards for an

eventual production console design.

It is more similar to those consoles that operate

planetarium shows than an actual organ, I guess,

so I know I am pretty far afield.

Hence, the need for me to devour all I can on this

forum before I present my true desires to an

organbuilder. The ones I’ve talked with really raise

an eyebrow … 'nuf sed.

Some of the green and blue tabs on my unique organ

have nothing to do with organ whatsoever; I have

merely expanded the capability of those organists who

trigger mirror balls and spotlights or control

toycounter effects from their instruments.

Because I use an NSI MIDI-controlled theatrical light

mixer for my productions, I know it is possible to

incorporate MIDI for non-musical controls.

Why could I not employ such non-musical triggers as

computer up/down cues for my PowerPoint and

9-projector multi-media slideshow, as well as electric

motors for curtains, waterfalls, etc.?

When, may you ask, does a person have time to perform

organ and still operate all these gadgets? That’s a

valid question, I have to admit … "Don’t pay any

attention to that green man behind the curtain, Toto!"

(heh!).

Of course, these non-orgel tabs will be duplicated

on a separate dedicated MIDI production console via

a duplicate MIDI stream for a technician to operate

with video remotes, etc., but the museum show producer

in me may have a desire to work through the midnight

hours without an entire staff to operate the controls

as I tweak and create.

Although I am a producer limited in performance

technique, I believe theatre unit-orchestra can fill a

need for today’s audience (that resorts to mosh pits

and violent on-stage theatrics because they haven’t

been exposed to the full potential satisfaction of

what a contemporary organ can provide in a live media

application performance).

19

Hello  Paul,

I am sure that Per S has given you some good advice concerning your project.  I also am a recepiant of his advice and can’t say enough about his patience and help.

In your research, you should take a look at jorgan (http://jorgan.sourceforge.net) and log in on the forum (http://jorgan.sourceforge.net/forum/index.php?sid=defc131555d02937d23b381073edf5ca) jOrgan is a virtual organ similarly constructed as miditzer, but capable of operating from  from a conventional console without need of a computer monitor.  The monitor is necesssary and helpful, but not needed at the console. In addition, jorgan can be configured to trigger pipe magnets for use concurrently with the electronic ranks.

My project is to build a hybrid organ using jorgan and pipes.  My console is a moller 2 manual which was converted to midi using the midibox technology. So far there are 3 ranks of pipes with companion blower, regulator, windchests, etc., and I am in adding the driver boards, etc. for powering the magnets.  With jorgan, you have a choice of staying with a classical organ or theater (cinema) organ as you like.  jorgan is capable of functioning as the master control system, and can do just about anything that you can do on a conventional organ console.

I would be glad to respond in greater length by email if yo so desire ( jwcouvillon @cox.net).

Regards,

johnc

20

The Miditzer is also capable of being used without the computer screen, mouse, or computer keyboard.  It is just less aparent since the Miditzer is designed to make it very easy for a new user to get started and so it presents those interfaces as something everyone will have.  You can also drive any output device you want including MIDI controlled pipes.  Again less obvious because the Miditzer tries to be sure everyone will hear something without effort.  I believe jOrgan now has a way to tie a rank to a specific MIDI channel which is needed for real pipe control but that has always been inherent in the Miditzer.