My organ midification project

MIDIfication
, ,
1

Hi,

 

I have just acquired a stripped out rodgers organ + pedalboard which I would like to use for an organ midification project. I have been roaming this forum for about a month, trying to collect the information and wanted to ask if you could give me some advice and make me aware of caveats which I hadn’t considered yet.

 

The organ consists of:

 

2 x 61 key manuals: each in 4*16 diode matrix

pedalboard: 2*16 diode matrix

43 stop tabs (SAMS)

31 piston switches

1 swell pedal

 

I think I will need:

Control module: LPC17 + LPCxpresso

Manuals + pedalboard: DIO matrix board

stop tabs + piston switches: 3 * DIN Module

SAMS action: 3 * DOUT module (switching to the on state uses one channel, switching to the off state uses another: 2 * 43 channels, are the line drivers rated for enough current?)

swell pedal/Pot: should be accomodated by core module

 

Does this look about right? Does one core module support all this. What latency/conversion times would I have to expect. Re latency I read about the midibox kb project which is in development but I’m not sure if this is simply a firmware update or also different hardware or if it is applicable at all to what I want to do.

 

I was thinking of using the manuals in a 16*16 matrix. With both manuals and pedalboard I am at the moment 10*16 but I want the option of extending by a manual in the future and I assume that it is not easily possible to scan in numbers which are not powers of two anyway.

 

I wonder if you could also give me an indication of how much programming I would likely face (something I’m not worried about). In particular the SAMS might be tricky in that I need to control the two lines per channel via one midi signal. On an off-on trigger edge the on coil would need to get engaged for 100-200ms and on an on-off edge the off-coil. Does anyone have experience how easy it is to configure midi out in Hauptwerk anyway … might be lost cause after all.

 

I would really appreciate your feedback.

 

thanks a lot!

2

Hi,

 

I think that MIDIbox NG would be the best choice for such a project: http://www.ucapps.de/midibox_ng_manual.html

 

The “programming” is script based (see “First Steps” in the manual) and therefore easy to adapt for your needs.

MBNG contains the same driver like MBKB -> KEYBOARD configuration, see also the kb_*.ngc examples under http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2F

 

Latency: then less rows are used in a matrix, then lower the latency.

MBNG supports up to 16 independent matrices, so that there is no need to create a 16x16 matrix.

Scan cycle is around 250 uS * <rows> as far as I remember

I would say, that everything which is below 1 mS can’t really be recognized.

 

I can’t answer the questions related to the SAMS hardware

 

Best Regards, Thorsten.

3

Hi Thorsten

 

thanks for your reply. There is still a limit of 16 DI registers per controller in place isn’t there. So if I split up the matrix into less rows I would need to go towards two controllers wouldn’t I. Will send some PMs out to the people that have stated that they have successfully driven SAMS with midi box hardware and will post my findings here for other people that might run into the same problem.

 

Off topic: do you think that this might be a future platform for midibox?

http://www.raspberrypi.org/raspberry-pi-compute-module-new-product/

4

For MBNG the limit has been relaxed to 32 DINs and 32 DOUTs

 

Btw.: meanwhile there are also new methods which allow to connect the modules over long distances by using RS-422 like line drivers: http://www.ucapps.de/mbhp/line_drivers.pdf

 

 

Off topic: do you think that this might be a future platform for midibox?

 

Not really, RaspPi has been made to run Linux, and no “bare metal” applications which give you direct (fast!) access to many IO pins and interfaces.

MBHP_CORE_STM32F4 is superior for MIDIfication purposes compared to such SoC architectures.

 

Best Regards, Thorsten.

5

Mumblecake,

I didn’t mention, but i am using two KB modules with the LPC17 for 3 KB’s and SAM sense contacts.  I started out with a 16x16 matrix, but the simplicity od the KB’s in conjunction with the LPC17 changed my mind.  I also built the SAMS sense matrix by putting the diodes directly on the SAM, and building the matrix with jumpers, resolving to 2 8/c ribbon cable to the KB module.  Probably a big antenna, right.  Live and learn!  while having the spontaneous action, i did a wiring consolidation, separating the wiring from the douts to the  SAMS  from the wiring for the sense matrix to the KB modles.  That helped a good bit.  considering the spread of wires connecting to the DINS or the DIN side of the KB modules,  the only way to do a better job of isolation would be to use shielded wiring.

When I started out with midification (2004), All i could see was the potential applications, with no specifics or input to tell me that in the end, it may be going a bit too far.

I still feel that if i worked  with it long enough, I could resolve the issues. At 75 years old,  it is becoming difficult to see the small stuff, and to keep the details straight in my aging, slow memory.

Johnc

 

6

Thank you Thorsten and John (also for the extensive message detailing your past experiences and considerations!)

 

In order to reduce the scan time it seems crucial to keep the number of matrix rows to a minimum.

 

I can drive each manual as two separate 2*16 matrices. Making with two manuals and pedalboard overall five 2*16 matrices. I take it the best approach here would be to use a separate matrix DIO board for each, so 5 matrix DIO boards (making 10 DI and 10 DO chips … 22 to go).

 

The 31 piston switches + 43 stop inputs (74 DI channels) are accommodated by another 3 DIN module (adding another 12 DI chips)

 

The 43 SAMs (86 DO channels) are then controlled by another 3 DOUT modules (adding another 12 DO chips) regardless of how they are buffered on the other end.

 

The Pot of the swell pedal should go directly to an AI channel of the Core module

 

so overall:

 

LPC17 core

5 x matrix DIO module

3 x DIN module

3 x DOUT module

 

Does this look about right and does one core module really support all those modules.

 

With all matrices having been reduced to two row matrices, can I expect a latency of less than 1ms or is that calculation too naive?

 

I also wanted to ask if the scripting language allows to include proper logic?

 

Considering the midi signal for one of the stop switches. Let’s assume that the switch is off. This signal is set by the respective DI channel of that switch and sent out via midi to the computer.

 

The computer now wants to change the switch from off to on and sends out the changed midi signal. At the controller I would now like to do some logic choices. When ever the state of the computer midi signal changes, one of the 2 associated AO channels needs to be engaged for about 100ms but only if the latest DI channel reading is different from the computer midi signal.

 

A few examples:

 

Switch is off. I manually switch it on. This sends out a changed midi signal to the computer. The computer will repeat the changed signal and send it back. As the switch is already in the requested position I don’t want any of the output channels to engage.

 

Switch is off. I press a combination button and the computer subsequently sends out the change request. As the switch is not yet in the desired position I want the correct AO channel to engage for 100ms to automatically change the switch position.

 

Is this kind of logic involving direct signals and in-/out going midi signals as well as states of previous iterations possible? I would probably also have to include a timeout until the switch can get automated the next time (~150ms to make sure that the switch is stable in it’s new position and doesn’t immediately gets switched back). Will there be a significant overhead?

 

As always your thoughts are highly appreciated.

 

thank you very much

 

best regards

 

Mathis

7

Hi Thorsten,

 

re logic I have now read a great deal through the ngc and ngr documentation. It looks very much like the ngr scripts would be doing pretty much what I want. Question though is, when I run the script via a defined meta event, and the meta event is fired again while the script is still executing, will it enqueue the script so that it will start immediately again after the previous one has finished? Also is the script blocking so that no other script can execute or that the AI/DI/DO data acquisition gets blocked (can’t imagine the latter)?

 

cheers

 

Mathis

 

edit: I’ve also noticed that the smallest amount of rows for a scan matrix seems to 4. Does that mean I can reduce the amount of DIO matrix modules to three?

 

edit 2: ohh, I get it. You can only define one script file which can contain multiple scripts which are selected by chosing the section. Still the question if the script gets re-enqued when the trigger is fired while it is still running or if the trigger gets ignored in this case.

8

After exactly 8 months and 1 day I have finally managed to get my virtual pipe organ into a playable state:

 

This is the organ console with attached touch screen monitor

<___base_url___>/gallery/image/2792-virtual-pie-organ/?do=embed

 

This is the console

<___base_url___>/gallery/image/2790-console/?do=embed

 

Here you can see the side of the console and a bit of the pedalboard and touch screen

<___base_url___>/gallery/image/2791-side-of-the-console/?do=embed

 

The pedalboard

<___base_url___>/gallery/image/2789-pedalboard/?do=embed

 

Here you can see the stop action magnets in action which are controlled via the touch screen:

http://youtu.be/_HQcKWEX9Hc

 

The sense of achievement is phenomenal after all this time. Thanks to everyone who helped me on the way. Thank you very much in particular to TK without whom this project would not have lifted off. I will try to compile some documentation for others who might be interested to do a similar project.

 

Best Regards

 

Mathis

9

:thumbsup: