Our GrandOrgue users

    • Offizieller Beitrag

    Please let us know something about you !

    May be you will answer us some of the following questions, or write what ever you want.

    • Where did you first hear about GrandOrgue?
    • When did you hear about GrandOrgue?
    • Do you use GrandOrgue as your only virtual organ?
    • What is the kind of your hardware using with GrandOrgue (Computer, Keyboards, e.g.) ?
    • Which sample sets do you use with GrandOrgue?
    • Which sample sets do you miss for GrandOrgue?
    • Are you satisfied with GrandOrgue?
    • Do you have some suggestions to integrate in GrandOrgue for the future?

    Thank YOU - this may help us and the developers of GrandOrgue,
    and will also help you to get most out of your virtual organ in the future.

  • 1) I heard about GO from Graham Goode
    2) Have been using for about 3 years
    3) I use mostly GO
    4) I'm using a AMD computer, 4-core, 8 gig RAM running at 3.2gh
    The program is Windows 7 pro 64 bit
    The keyboards are Yamaha 220s extracted from the outer case
    and connected via MIDI/USB cables to USB ports
    The keyboards are directly connected. The pedal board is a used Rodgers. It and the pistons/swells
    are controlled by John Kinkennon's midi relay interface with Dout and Din boards from Midibotique
    The soundcard is an EMU1212. and is connected to an 100 watt Onkyo stereo receiver by ADAT. The
    sound system is Cambridge speakers with a Dayton Audio 250watt subwoofer with a 15 inch dual coil
    speaker
    5) I'm playing with a custom organ put together by Graham Goode and myself from 4 organs of GO samples
    There are 4 divisions plus pedal. Gt, Sw, Pos, Solo. There are about 100 stops. The samples sets are
    from 4 GO organs: Burea Church, Kalvtrask Church, Pitea School, Barton Theater organ.
    The name of this custom organ is OMNI. This is similar to the Augustine's organ sets, but they don't
    include the Barton as Omni does. This rather large organ fits into an 8 gig RAM. Would never work with
    Hauptwerk---too large
    6) I'm always looking for certain stops to enhance OMNI, but it is pretty good the way it is.
    7) Grand Orgue is amazing for what it does, but their are problems with it. It doesn't get the attention
    it should. The OMNI organ combination action is not totally functional. And there are random thumping
    sounds, mostly bass, that get in the act.
    8) It would be nice if future versions of Grand Orgue had old bugs fixed, especially auto-save. It would be
    nice if the latest versions worked flawless, but they don't. I'm using version 1726 because the newer
    ones have bugs, and will not allow me to OK certain menu selections, or some other problems. There
    should also be a resident Convolution reverb with Jack backend built in. The resident IR reverb isn't bad,
    but it has some keying problems.

    The OMNI sample collection is eclectic or universal, and can play almost anything, including transcriptions. It is, of couse, not a baroque organ, but it does play Bach pretty well. There are of course, numerous baroque organs available, so that's not a problem.

  • Do you intent to publish it?

    Zitat


    The OMNI organ combination action is not totally functional.

    What problems do you refer to.

    Zitat


    And there are random thumping sounds, mostly bass, that get in the act.

    If it is a bad loop, you can overwrite the loop via ODF. Or there is loop crossfade as last resort.
    Otherwise an example demonstrating the problem would be necessary.

    Zitat


    8) It would be nice if future versions of Grand Orgue had old bugs fixed, especially auto-save.


    The missing of auto-save is not a bug. It will only persist the changes, if you press (the also MIDI toggleable) save. This provides a kind of undo function.

    Zitat


    It would be nice if the latest versions worked flawless, but they don't. I'm using version 1726 because the newer
    ones have bugs, and will not allow me to OK certain menu selections, or some other problems.

    The hang is related to the audio drivers - so it is system dependend (and Windows releated). I'm not sure, what kind of backend is affected.

    Are the ASIO free versions also affected (so we can rule out ASIO):
    http://download.opensuse.org/repositories/h…/openSUSE_13.1/

    Zitat


    There should also be a resident Convolution reverb with Jack backend built in. The resident IR reverb isn't bad,
    but it has some keying problems.

    What do you mean?

  • Everybody should try OMNI I haven't heard form Mikelectric whether he is interested in posting to this website because of the mechanics involved.
    A pretty big file. He or some others should test it out first.
    This is a large multi-purpose organ. It fills a very big gap between
    all the small, mostly baroque organs that are available.

    As for the combination action, Graham didn't have time to finish it. It was supposed to have decade memory like the GO floating panel and some other organs offered. But if you move to the next decade, it overwrites, etc. There is a 10-ABC memory that works, but it is not quite enough. There are only 10 generals. Nothing else.

    The thumping is a left-over problem from earlier versions of GO. It mostly affects the bass on the manuals.
    That is 16 stops. It is random with releases, I think. I can't isolate or tell you more than that. It sounds like someone has turned on a high load in the house. Graham seems to know what it is.


    We don't need an undo function. It is very difficult to keep up with saving. Hauptwerk does it automatically
    In addition to the other problems, GO version 1726 crashes randomly from time to time, and I lose piston changes and voicing changes, if I don't constantly save. In any case, when you change pistons on a pipe organ equipped with capture combination action, it is saved and done. Why should GO be any different?

    I'm using an EMU 1212sound card with ASIO. It DOESN"T hang with v1726, but it does with 1919. I'll try the newer version now released. That is, when I attempt to make changes to audio, etc, I can't close the dialogue box. It won't accept the ok button. So I can't even set up an organ. This is not a old config file problem either. I've erased them whenever I try a new version. Why doesn't the GO software make a clean
    install, anyway?

    Setting up a stand alone convolution reverb is rather difficult for me, at least, to understand. It involves three other programs that need to be connected or set up to handshake. I simply don't know how to make it all work. The resident IR reverb is okay, but it always has to be okayed when I open the organ, otherwise there is a 1 second delay in keying. And if I stop playing for 10 seconds or so, and change pistons or pieces to play, the first note or chord sounds with a sudden burst. Don't have that without the reverb.

    So maybe fussy me, but there are legitimate problems. Someone who works with GO source code has to fix them.

    I don't know how non ASIO sound is affected because my setup is involved for the sound system, etc. I play this OMNI organ 6-8 hours or more a day, so it is heavily used. It is not a novelty or toy to me, but a real musical instrument. I've been playing OMNI for about a year, and its predecessor, Grahams' enlarged "AGO" version of the Burea Church for about 2 years.

    Because the sound files are smaller than Hauptwerk, OMNI fits on smaller RAM computers. So you can
    have a substantial instrument without overflowing the RAM. An instrument this size would take up an enormous amount of RAM---probably 45 -64 Gigs in Hauptwerk.

    I'll post a Dropbox link to a screen shot of OMNI. This forum says the file is too large.


  • Everybody should try OMNI I haven't heard form Mikelectric whether he is interested in posting to this website because of the mechanics involved.

    Trying requires, that you can download that organ.

    The legal situation of the organ needs be OK:
    Lars sampleset allow derived version licensed under the CC-BY SA. If you used material [graphics, samples] from other foreign sources, they also need a license, which allow you to modify and publish the result.

    Zitat


    As for the combination action, Graham didn't have time to finish it. It was supposed to have decade memory like the GO floating panel and some other organs offered. But if you move to the next decade, it overwrites, etc. There is a 10-ABC memory that works, but it is not quite enough. There are only 10 generals. Nothing else.

    It would be a lot easier for me, if you would post the ODF, so that I can look up, how the various elements are defined.

    What do you mean with "decade memory"? Do you mean the "sequencer"? What do you mean with "overwrites"?

    You and I are using different terms and you just use one or two keywords as error description.
    If you write more like "If I press A, then press B, then press C, GO does X instead of expected Y", I can provide better help.

    Adding more elements (eg. generals) is not complicated - I can provide you some hints, if tell me, what you want to achive.

    Zitat


    The thumping is a left-over problem from earlier versions of GO. It mostly affects the bass on the manuals.
    That is 16 stops. It is random with releases, I think. I can't isolate or tell you more than that. It sounds like someone has turned on a high load in the house. Graham seems to know what it is.

    So it is a release management bug: https://sourceforge.net/p/ourorgan/bugs/15/ ?
    Being able to test with the samples will probably be necessary.

    Zitat


    We don't need an undo function. It is very difficult to keep up with saving. Hauptwerk does it automatically
    In addition to the other problems, GO version 1726 crashes randomly from time to time, and I lose piston changes and voicing changes, if I don't constantly save. In any case, when you change pistons on a pipe organ equipped with capture combination action, it is saved and done. Why should GO be any different?

    Have you never accidentially kept SET on (or turned it on) and then destroyed combination, because they were overwritten instead of being recalled?
    I'm are not blessed with the skills, that every voicing change improves things.
    Being able to try out things and undo them by not saving is a really convinient feature.

    Have you tried GO under Linux? The crash reports are mostly Windows.

    There is a version, which you can install/boot from a USB stick without touching your windows installation:
    https://sourceforge.net/projects/ourorgan/files/GOLive/

    Zitat


    I'm using an EMU 1212sound card with ASIO. It DOESN"T hang with v1726, but it does with 1919. I'll try the newer version now released. That is, when I attempt to make changes to audio, etc, I can't close the dialogue box. It won't accept the ok button. So I can't even set up an organ. This is not a old config file problem either. I've erased them whenever I try a new version. Why doesn't the GO software make a clean
    install, anyway?


    If you close the setting dialog, GO reinitialisies the sound output (closed/open the sound driver). This hangs on your system. This is system dependend as your sound card driver is part of that process.
    GO supports various sound driver models (WMME, DirectSound [using PortAudio or RTAudio], ASIO [using PortAudio or RTAudio], WDM/KS, WASPI), so there are many potential error sources. This needs to be narrowed down.
    My last builds include no ASIO, so a hang with them would rule out a bug in the ASIO code.

    I also need to know the exact title of the sound card in the GO audio settings, which triggers the hang (as well as the previous title, if you changed this setting).

    Zitat


    Setting up a stand alone convolution reverb is rather difficult for me, at least, to understand. It involves three other programs that need to be connected or set up to handshake. I simply don't know how to make it all work. The resident IR reverb is okay, but it always has to be okayed when I open the organ, otherwise there is a 1 second delay in keying. And if I stop playing for 10 seconds or so, and change pistons or pieces to play, the first note or chord sounds with a sudden burst. Don't have that without the reverb.

    There is an experimental GO build using a different reverb engine:
    http://mps-net.de/mk/20150401/index.html

  • Hi Folks.
    I heard about, & tried HW first, and found GO while I was digging for info on HW sets. (Free ones of course!) I've played with both for a few months, and prefer GO, basically because it accepts any size set, while HW is limited to about 2G unless you part with oodles of cash! I've tried this in our church (I am principal organist, and responsible for upkeep of our electronic organs.) It works very well, when driven with an old Wyvern machine, once I discovered that for some inexplicable reason they had inverted the MIDI polarity! (Used an oscilloscope to sort that out!)
    At present I've only used the windows versions, but I've tried the GO live linux version as well. The problem with linux is that I'm using the M-Audio Delta sound cards, and the drivers don't appear to be on that version. (I think its 'Envy24' that's needed?) It worked very well on an old laptop though, and, interestingly, through the HDMI output on my main machine.
    I've played with Burea and Pitea and St Annes on windows HW, but I like the extended Burea on GO.
    However, I think I need to get GO running on linux before I could use it live in church. Comments?
    trouble is though, although I do use linux quite a lot (PCLinuxOS), I'm not very familiar with installing things not in the repository, so I'll be hoping for lots of help :) :) :)
    Regards to all.

  • Thanks Martin, that's a good starting point. I've got it working on a laptop, using the onboard soundcard, but I haven't yet managed to get the drivers sorted out on my desktop for the M-Audio Delta series cards. I know it's the Envy24 , but I haven't got it sorted yet.

    As an aside though, when I try to add more channels, (on a windows machine) using a second card, I get the 'not supported' warning, but then it goes and works anyway. the thought crossed my mind that this may be because the cards are nearly identical. Any comments?
    JZZ

    • Where did you first hear about GrandOrgue?
    • When did you hear about GrandOrgue?
    • Do you use GrandOrgue as your only virtual organ?
    • What is the kind of your hardware using with GrandOrgue (Computer, Keyboards, e.g.) ?
    • Which sample sets do you use with GrandOrgue?
    • Which sample sets do you miss for GrandOrgue?
    • Are you satisfied with GrandOrgue?
    • Do you have some suggestions to integrate in GrandOrgue for the future?


    1. Somewhere in internet. I do not remember exactly
    2. About 4 years ago
    3. Yes, I do.
    4. I use a gametable with three manual keyboards an a pedalboard. Each one is connected directly throught USB.
    I use a desktop computer (i7 2600K overcklocked to 4.8 GHz, 32 Gb RAM, SSD RAID0 2*128 Gb, HDD RAID1 2*2 Tb).
    There are two seats connected with the computer: the first one has a monitor, a keyboard, a mouse and an USB Hub). The second one has a game table, two monitors, a keyboard and a mouse. There are two Nvidia videocards for handling two separate seats. There are no touchscreens.
    There are two audio interfaces used with GO: MAudio Delta 1010 lt - for headphones, and HDMI output on a videocard for multi-channel sound speakears (through a AV Receiver). MAudio Delta provide less latency than nvidia hdmi output
    The computer is powered with Linux (Fedora 23). I always use the latest versions of OS and GO.

  • Zitat


    Which sample sets do you use with GrandOrgue?
    Which sample sets do you miss for GrandOrgue?
    Are you satisfied with GrandOrgue?
    Do you have some suggestions to integrate in GrandOrgue for the future?


    1. I use a composite sample set made by one from a doozen of another free sample sets III/P/80. It takes 24 Gb of RAM. Loading this sampleset takes about 1 minute from RAID0 2*SSD.
    2. I always enchance my sampleset with new interests free stops. I often replace my old stops with new ones that sound better. Sometimes I enchance tuning of my stops.
    3. Yes, I do
    4. I'd like to have native jack support (without PortAudio or RTAudio). It would require loading less jack modules and it would decrease latency.


  • 4. I'd like to have native jack support (without PortAudio or RTAudio). It would require loading less jack modules and it would decrease latency.


    Could you please explain this in detail?
    GO binaries can directly connect to the Jack Server - what kind of jack modules do you need to load?
    RtAudio Jack is a dumb wrapper around the jack libraries - what kind of the RtAudio code introduces further latency?
    Portaudio Jack support reblocking. Based on the desired latency and the GO + jack samples per buffer, it adds some buffering - this also provides more stable audio output.

    PS: If you want to reduce latency, reduce the GO Sample per Buffer setting.


  • Could you please explain this in detail?


    https://sourceforge.net/p/ourorgan/feature-requests/52/


    GO binaries can directly connect to the Jack Server - what kind of jack modules do you need to load?

    My multichannel setup is quite complex. It has two front speakers, one subwoofer and two back speakers. I use

    Because I use a composite set from different organs with different reverb time: both dry and wet, I need to make some additional software reverb for dry stops only. I use another software reverb for back speakers for stops that are stereo-only (without back channels recorded). I need a low pass filter for subwoofer and a high pass filter for back speakers (otherwise my AV receiver raises a protection and switches off when I play bass voice). I use four instances of Jack Rack. with Zita Reverb, stereo amp and simple filter plugins and a complex distribution of ranks among jackrack modules.

    If a stop is wet and 4-channel, its front channels are connected to the front speakers directly and its back channels - to the JackRack with the high pass filter for the back speakers.
    If a stop is wet and 2-channel, I connect it to the front speakers directly and to the JackRack-Reverb for back speakers.
    If a stop is dry and 2-channel, I connect it to two JackRack-Reverb instances - one for front and another for back (they are have different parameters). And all stops are connected to Jack-Rack-Low Pass Filter for the subwoofer.

    So the PS & RTA approach that GO connects to only one soundcard or program is not suitable for me. No I connect GO to some 8-input-port jack fictive client and then didtribute each GO output port to several outputs with Jack Patchbay. This jack stacks bacame complex and using a fictive jack client adds more complexity. If GO could only expose jack output ports without connecting them byself, I wouldn't need to use the fictive client.


    RtAudio Jack is a dumb wrapper around the jack libraries - what kind of the RtAudio code introduces further latency?
    Portaudio Jack support reblocking. Based on the desired latency and the GO + jack samples per buffer, it adds some buffering - this also provides more stable audio output.

    PS: If you want to reduce latency, reduce the GO Sample per Buffer setting.

    I use 64 samples per buffer with 5 jack buffers at 96000 hz for m-audio delta (headphones) and at 48000 hz for HDMI output. If I se up less samples per buffer or increase freq, the sound distortion appear: the power of my i7-2600K 4.8Hhz bacomes not sufficient for handling this. Eliminating some jack clients would reduce the amount of work for my CPU and would allow me to set less samples per buffer without sound distortion.

  • Another my suggestion is to separate rank-to-audio channel distribution and midi settings from another organ settings.

    I often change my organ definition file. Mostly I change pitch tuning or a volume of some pipes, but sometimes I replace stops with another or redistribute them between manuals. Because merging of modified odf with the old organ setting file brings unpredictable results, I always delete the organ setting file each time the ODF is changed. But I always loss the distribution of stops among audio groups. Because the quantity of stops is big and the distribution rules are coplex, it takes a lot of my time. I'd prefer to have capability not to loss the stop distribution after changing odf.

    One possible solution would be to store sound distribution setting separatelly from another organ settings. Another possible solution - to have preffered audio group names for ranks in odf and match them with existing audio groups.

  • 64 samples per buffer with 96kHz means GO has 0.67 ms for each buffer. This means, that GO has to distribute the calculations across all cpus during that period and finally collect/merge the results.
    What is your CONFIG_HZ? The scheduler slot size might even be larger than this window, so loosing CPU probalby means loosing CPU for multiple buffer calculations.
    Note, that lowering samples per buffer will increase the necessary CPU power, as there is more overhead for synchronisation, ....

  • Your setup is very, very special.

    Just to add:
    I don't think, that eliminating the patchbay would allow you much lower samples per buffer. You could test this by temporary rewiring the GO jack connections.
    From the GO perspective, use less larger buffers. 2-3 buffers of 128 should provide an equal GO latency as 5 buffers of 64 with a lower CPU usage.

    In regard to storing audio groups in the ODF:
    Any proposal must be universal - it should work from a simple stereo setup to a giantic multi-channel setup. Simply allowing to store random strings will not ensure that.


  • From the GO perspective, use less larger buffers. 2-3 buffers of 128 should provide an equal GO latency as 5 buffers of 64 with a lower CPU usage.

    I've already tested this. 5*64 is more stable and brings less xrun's than 3*128.

    I use 5*64*96000 only for headphones. I use 5*64*48000 for loud speakers, because the intel hda hdmi sound chip embeded in the nvidia videocard works unstable at 96000 with small buffers. Of course, the AV receiver brings additional latency - about 20ms.


  • In regard to storing audio groups in the ODF:
    Any proposal must be universal - it should work from a simple stereo setup to a giantic multi-channel setup. Simply allowing to store random strings will not ensure that.

    The same approach was used for attaching manuals to midi devices: you have introduced the MIDIInputNumber value. Each setup has own quantities of midi keyboards, but MIDIInputNumber allows to match ODF settings with certain hardware.
    Storing the preferred audio groups for stops/ranks would bring the same capability.

    If you are talking about the universal solution, another approach would be
    1. Make the single flat scope of parameters for ODF and setting files. All parameters must be the same
    2. The settings in the setting file override ones in ODF
    3. Store only the overriding values in the setting file. All absent values should be inherited from ODF

    This solution would be the most universal. This would dramatically improve the merging capability of changed ODF with the old setting file. But I understand that this approach would be more convenient for IT specialists than for organists. Most of organists would prefer that you decide for them, which setting they should or shouldn't change.

  • The manual config is easy: Organs just feature one pedal and 1 - 3 (or 4,5 less likely) manuals. Same for enclosures.

    Audio routing is not that simple. Simply specifing a random audio group name in the ODF will not aid any preconfiguration for the mass.

    * According to your posts, you will probable have a "audio group without reverb", a "audio group with rear reverb", a "audio group with full reverb" [or even more].
    * A stereo user will just have one audio group.
    * Another user will have a front and a rear audio group.
    * The example in our help includes a rear, front, "front (soft)", left and right audio groups.

    So what audio group names should a ODF creator specify in the ODF?

    ODF and settings are district for reason:
    ODF is a stable file format, which theoretically could be implemented by any program.
    The settings are a dump of the GO internal state and may change in any way, as the GO internals change.


  • * According to your posts, you will probable have a "audio group without reverb", a "audio group with rear reverb", a "audio group with full reverb" [or even more].
    * A stereo user will just have one audio group.
    * Another user will have a front and a rear audio group.
    * The example in our help includes a rear, front, "front (soft)", left and right audio groups.

    So what audio group names should a ODF creator specify in the ODF?

    Three audio groups would be enough in most cases: "default", "front" and "rear".

    One extra group may be useful for for composite sample sets only: "dry", that requires external reveberation.