My new old organ project

  • I've just started learning about virtual pipe organs, and have possibly rashly decided to build one.

    Here's the plan:
    [list type=decimal]
    [li]Acquire an old Allen organ[/li]
    [li]Remove the sound generation and most of the other electronics[/li]
    [li]Program some Arduinos to scan the manuals, pedalboard and stop tabs[/li]
    [li]Hook it all up to an old Mac Pro running GrandOrgue[/li]
    [li]See what comes out![/li]
    [/list]

    I started by installing GrandOrgue on my main computer and testing it out. I don't have a MIDI interface, but was able at least to understand the workflow and load a few different organs. It's very intuitive so far, and I'm enjoying the sound.

    I looked around for available MIDI conversion products, and clearly there are many. But I thought it might be more fun to create my own.

    I thought I might post my progress if people would find that interesting...

    Tim

    • Offizieller Beitrag

    Hello Tim,

    that's a good idea and will surely work proper when finished. I treated two older organs (Eminent and Ahlborn) like that and it makes a lot of fun to hear these now in excellent sound quality. First I used midi electronics which I made myself with the PIC microcontrollers. Nowadays I use components from http://www.midihardware.com.
    Have a lot of pleasure doing this.

    Mike

    p.s. Would of course really be nice to post the progress here...

  • Hi Mike,
    It is looking like a lot of work, but fun. I bought an organ on Ebay for 99c and spent yesterday pulling it apart. It's a pre-MIDI, analog organ, so there's going to be a lot of reconstruction. The good news is it should be a couple of hundred pounds lighter when I'm done. The tone generator, power supply and amplifier are amazingly heavy (which is probably partly why they were still working after 50 years.

    I don't think I can manage with the restrictions to image size here, so I may look for a different forum that allows larger attachments, but I'll attempt to add a picture of the organ on my trailer arriving at the house.

  • The only downside of Linux in my application is that I'm not sure how I would link iPads up to control registration.

    I can set them up either as extension screens, or with a Midi app that lets me map screen touches to stops.

    Are there any utilities to do that with Linux?

    Thanks,
    tim

    • Offizieller Beitrag


    I don't think I can manage with the restrictions to image size here, so I may look for a different forum that allows larger attachments, but I'll attempt to add a picture of the organ on my trailer arriving at the house.

    I have now increased the limits for the file attachments. If it is still too little, I can also go higher. ;)

    What is this organ model? It looks nice.

  • Hello Tim,

    Good luck with your project! I am in the middle of converting an 1970's Rodgers 725CE organ myself. I used arduino's to create a key scanner and midi controller. I was also able to design some PCB's to control the stop tabs as well. Please post a video online when your done, it will encourage me to finish my own projec

  • Hi timbarnes - We closed down our old MIDI equipment company a number of years back and I am retired now. I am building my organ with Grand Orgue and will be using our final product the M128/256 which is a 4-channel PIC Micro-based board interfacing in a standard 8x8 matrix for each division. We had some real fun recently developing a special note splitter board to add spatial expanse to Grand Orgue. The catch is that you need multiple computers and I am using 4 different quadcore LINUX 64 boxes with 16GB RAM. The MIDI Interfaces to the computers are about $7 on EBAY. I believe LINUX MINT 64 is the best for Grand Orgue. The only issue I recently had was the need to fallback to an older version of Grand Orgue because the newer one created intermittent clipping of the sustained sounds. I use 3.1.2084 version now with no clipping glitches. My LINUX boxes (used) were $235 each. For real fun move an organ to another LINUX "workspace" and open another copy of Grand Orgue with a different organ. I currently play an ensemble of 4 organs - Barton, Wildervank, Kalvtrask and OMNI. The TUTTI is magnificent.

  • This is very interesting. I am going to try the live distribution of GrandOrgue to see how it works under Linux. In the past when I've tried to work with Linux I've not found my command line skills up to the task, and getting sound cards etc. that work properly hasn't been easy either. I do use Linux on Raspberry Pis with mpd as music clients to deliver music from a central server.

    Right now I'm running Mac OS on an old Mac Pro, and it seems to work fine except for some RTMidi error messages. I'm going to start with the internal sound capability, but my goal is to get to a multi-channel system once I get the basics right.

    I did my own MIDI boards using Arduino Leonardo and Pro Micro boards, because they output MIDI over USB, which is less interfacing effort for me, and a single cable carries power and data, so internal control wiring is just four USB cables.

    I haven't yet had the chance to do much with the organ sample sets, because I'm still building the organ (one manual and the pedals implemented so far). I'm looking forward to that stage in the process.


  • It looks as though I could use a VNC application


    This is also a (very long term) plan for GOLive. Defining one large virtual screen in xorg.conf and exporting it by defining VNC monitors using the Xorg vnc module and maybe also allow a remote access to the main screen too.
    libvnc.so might need some enhancement for this.


  • I did my own MIDI boards using Arduino Leonardo and Pro Micro boards, because they output MIDI over USB, which is less interfacing effort for me, and a single cable carries power and data, so internal control wiring is just four USB cables.


    If you use multiple MIDI interfaces, you need to make sure, that OS X provides a stable device identification.

    GOLive (or any bleading edge Linux distribution) support such IDs by recognizing the used USB ports.

  • I put each micro controller on a separate channel. No issues so far.

    Last night I hooked up one manual and pedals and was able to play music for the first time!

    Still lots of work to do - the second manual, stop tabs (I'm sanding the old labels off!), and audio system.

  • Well...now I have two Arduino Leonardos - one for a manual and one for the stop tabs. MIDI Monitor shows that both are happily generating messages, on different channels. MIDI Monitor can see both Arduinos (both are listed in the source selection), but GO only seems to see a single Leonardo, and is not accepting messages from the new one.

    If I disconnect either one, the other registers with GO properly, so I don't think it's an issue with the Arduino programming or hardware. I had hoped GO would "blend" them into one source, using the different channels to distinguish between the message and thus allow both.

    Any thoughts about how to go about this?

    Thanks,
    tim

  • Thanks, Martin. I find that Hauptwerk can distinguish between identical USB devices on Mac - is there a chance that GrandOrgue will get an update to support this on Mac?

    I built GO myself last night, and did successfully create a package which runs, but it seems to have problems. Sometimes it crashes on startup, and it complains that Jack is not running (which the pre-built versions don't).

    I am frankly well out of date in terms of programming skills, so while I was able to get the package built, I'm probably not up to debugging it.

  • You can study the official GO builds: https://travis-ci.org/e9925248/grandorgue [Master branch].

    OS X is the platform with the worst GO support. If you are able to capture a OS X crash report of GO, I can look at it.
    I currently don't have any plan to work on the OS X device name topic.

    You want to make the return values of MidiInCore :: getPortName and MidiOutCore :: getPortName (RtMidi.cpp) unique for both devices, while they their mapping to the hardware interface should stay stable.


  • The only issue I recently had was the need to fallback to an older version of Grand Orgue because the newer one created intermittent clipping of the sustained sounds. I use 3.1.2084 version now with no clipping glitches.


    Clipping is triggered by overcommting your computers resources. Old GO versions just finish the full caluclations, regardless if that means, that it will finish too late and there can be audio dropouts [very short load spikes can be hidden by multiple audio buffers, which increase latency].
    Newer GO versions start reducing their load, if there is not enough time. Either background activity steals CPU time or the polyphonie is too high.