I've got an interesting application. I want to create a MIDI interface 
for a pipe organ. My father and I are building the interface hardware 
from scratch.

This organ has electrically-operated valves. We need (1) hardware 
interface to the organ circuits, (2) software to read and write MIDI events.

I was thinking of doing the software in Csound. I was thinking that we 
could use a regular sound card as a serial interface to the organ 
circuits (my father will build hardware to decode it, like a bank of 
shift-registers). Using a regular sound card means we don't need any 
other special interface hardware.

And the software could be done in Csound, which provides the real-time 
interface to the sound card and MIDI system, meaning I don't have to 
learn to program and debug those things in C++.

However, as you can imagine, some algorithms with loops and other 
"normal programming" constructs will be needed.

So my first question is what happens with a-rate opcodes when you write 
loops at k-rate? Does the a-rate pass ignore all flow control entirely 
and just move through every a-rate opcode in the instrument?

Secondly, perhaps we should do the logic in Python. We do need some 
significant speed.. the ability to resolve timing of events to within 1 
ms hopefully. Is there any significant overhead in calling out to 
Python? Can Python "see" Csound data structures like tables, or can 
arrays be passed to and from Python?

Thanks,
Mike

Mike, 

As an organist and programmer, I am not sure that I would use Csound for
this task. If you really do not want to use C, then use Python directly.  I
would guess that Python will be much faster by itself than Csound given the
circumstances.  Csound has too many things to worry about with timing
resolution and as you point out, the unusual control structures and lack of
proper data structures.  There is a Python Midi library out there somewhere
and Python has the other tools you will likely want.

You will probably want your Midi system to be able to control the
combination action as well (at least I would ^_^).  Custom Python scripts
could be written depending on the performance requirements of a particular
piece of music and with a computer at the helm, essentially limitless
combinations and setups could be easily stored and recalled.

Midified pipe organs are becoming much more common these days.  There are no
doubt commercial kits that could be installed as well.  (Try a company
called "Solid State Organ Systems" - http://www.ssosystems.com/ ).

Sounds like a fun project!!  Please keep me informed of how it goes.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


Michael P Mossey wrote on 1/5/09 6:58 PM:

> I've got an interesting application. I want to create a MIDI interface
> for a pipe organ. My father and I are building the interface hardware
> from scratch.
[...]
> And the software could be done in Csound, which provides the real-time
> interface to the sound card and MIDI system, meaning I don't have to
> learn to program and debug those things in C++.
[...]
> Secondly, perhaps we should do the logic in Python. We do need some
> significant speed.. the ability to resolve timing of events to within 1
> ms hopefully. Is there any significant overhead in calling out to
> Python? Can Python "see" Csound data structures like tables, or can
> arrays be passed to and from Python?

Hi Anthony,

Anthony Kozar wrote:
> Mike, 
> 
> As an organist and programmer, I am not sure that I would use Csound for
> this task. If you really do not want to use C, then use Python directly.  I
> would guess that Python will be much faster by itself than Csound given the
> circumstances.  

My concern is that I've never done real-time audio or MIDI in Windows. 
So at least Csound already takes care of that. Maybe there are existing 
Python modules for doing real-time audio and MIDI?

(The reason I mention audio is that I expect to use a soundcard as a 
serial interface to the organ hardware.)

If we use C, are there free compilers for Windows? Are there good 
examples of working code for realtime audio/MIDI, like maybe the source 
for Csound?

> You will probably want your Midi system to be able to control the
> combination action as well (at least I would ^_^).  Custom Python scripts
> could be written depending on the performance requirements of a particular
> piece of music and with a computer at the helm, essentially limitless
> combinations and setups could be easily stored and recalled.

That would be a step beyond. We might not get there. The organ is my 
Dad's hobby.. 8 ranks, installed in his house. However, he discovered 
that it's hard to keep it functioning. The valves break and the pipes go 
out of tune. So getting it to play at all is fun in itself. My Mom is an 
amateur organist and provides the music on those occasions we can get 
the thing to function.

It's an Austin organ from the 1920's.

> 
> Midified pipe organs are becoming much more common these days.  There are no
> doubt commercial kits that could be installed as well.  (Try a company
> called "Solid State Organ Systems" - http://www.ssosystems.com/ ).

Cool link!

Hi Michael,

 >>
 >> Midified pipe organs are becoming much more common these days.  There
 >> are no
 >> doubt commercial kits that could be installed as well.  (Try a company
 >> called "Solid State Organ Systems" - http://www.ssosystems.com/ ).
 >

We've just been through the process of MIDI-enabling a 19th century 16' 
organ with the dorkbot group here in Edinburgh:

http://dorkbot.noodlefactory.co.uk/wiki/WaldFlote

I wrote all the firmware for the controller board. Although we used a 
Xilinx development kit for the embedded controller, that was a pragmatic 
choice and I suspect something like an Arduino would also operate as the 
controller - I'm just not sure about the timing. I personally don't 
think Csound is a good fit - because of the level you are working at, 
it's more of a embedded control problem than an audio/MIDI one you are 
trying to solve.

I have a magazine article coming out later this month on the details of 
the project but feel free to contact me off-list if you want more details.

Cheers
Gareth

Andres Cabrera wrote:
> Hi Gareth,
> 
> I'm wondering, Arduino boards (don't know about the xilinx) have only
> a few input and output ports, and they are certainly not enough. How
> can the information be multiplexed in those ports, and how do you
> decode it later? Are there timing problems with these?
> 
> Cheers,
> Andrés
> 

I think that Gareth's team used a similar strategy to my Dad's strategy: 
you have a long shift register with one bit for every key, let's say 60 
keys. You clock 60 bits serially into the shift register. So it only 
takes two signals: a data and a clock. I'll let Gareth explain more.

Note that as you clock the signals into the shift register, the output 
bit at any given point will be changing. It will only reflect its true 
state once the entire 60-bit word is clocked in place. However, because 
solenoids have a much slower response than the rate at which you are 
clocking the bits, this doesn't matter (probably).

Again, I'll defer to Gareth to explain how he did it.

My Dad's organ is not a tracker. It's an eletro-penumatic: the valves 
contain solenoids which operate from electrical switches in the console. 
This gives us an advantage in midi-enabling.

Mike

Michael Mossey wrote:
>Note that as you clock the signals into the shift register, the output bit 
>at any given point will be changing. It will only reflect its true state 
>once the entire 60-bit word is clocked in place. However, because solenoids 
>have a much slower response than the rate at which you are clocking the 
>bits, this doesn't matter (probably).

The 74HC595 chip has a separate pin for clocking to the output, so you can 
clock 60 bits through 'invisibly' before latching them to the output pins. 
You can clock at more than 20MHz so the time to do an update should be well 
under a millisecond with an Arduino (which can probably clock out about one 
bit per microsecond in a software loop).

Martin

Hi Andres, Mike,

> Andres Cabrera wrote:
>> Hi Gareth,
>>
>> I'm wondering, Arduino boards (don't know about the xilinx) have only
>> a few input and output ports, and they are certainly not enough. How
>> can the information be multiplexed in those ports, and how do you
>> decode it later? Are there timing problems with these?
>
> I think that Gareth's team used a similar strategy to my Dad's strategy:
> you have a long shift register with one bit for every key, let's say 60
> keys. You clock 60 bits serially into the shift register. So it only
> takes two signals: a data and a clock. I'll let Gareth explain more.

That's pretty much it, except with one addition - if you use 'HC595 shift
registers as we did, they come with an output register on the parallel
interface, so we used another output line from the controller to strobe
the shift register contents into the output registers after the refresh.
The controller only needs 3 output pins - if you have any more available,
you can split the shift regsiter chain into shorter lengths.

I think Arduino would be a pretty good fit as the controller - my only
concern is the performance, as you have to refresh the entire shift
register chain after processing each MIDI key event - I'm not sure how
fast Arduino bit-banging would be. Only one way to find out, I guess

> My Dad's organ is not a tracker. It's an eletro-penumatic: the valves
> contain solenoids which operate from electrical switches in the console.
> This gives us an advantage in midi-enabling.

Yup, you're already more than half way there - almost all of our issues
were mechanical in getting the solenoids mounted over the manual in the
right place.

Cheers
Gareth