Author Topic: Our GrandOrgue users  (Read 6125 times)

Offline mike

  • Administrator
  • Jr. Mitglied
  • *****
  • Posts: 61
    • View Profile
    • MPS Orgelseite
Our GrandOrgue users
« on: 12. June 2015, 03:45:58 »
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.

Offline ken

  • Neuling
  • *
  • Posts: 15
    • View Profile
Re: Our GrandOrgue users
« Reply #1 on: 16. August 2015, 03:08:42 »
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.




     

Offline martin

  • Jr. Mitglied
  • **
  • Posts: 78
    • View Profile
    • GrandOrgue
Re: Our GrandOrgue users
« Reply #2 on: 18. August 2015, 09:07:44 »
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

Do you intent to publish it?

Quote
The OMNI organ combination action is not totally functional.

What problems do you refer to.

Quote
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.

Quote
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.

Quote
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/home:/e9925248:/mingw/openSUSE_13.1/

Quote
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?

Offline ken

  • Neuling
  • *
  • Posts: 15
    • View Profile
Re: Our GrandOrgue users
« Reply #3 on: 18. August 2015, 16:58:02 »
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.



Offline martin

  • Jr. Mitglied
  • **
  • Posts: 78
    • View Profile
    • GrandOrgue
Re: Our GrandOrgue users
« Reply #4 on: 18. August 2015, 21:53:41 »
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.

Quote
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.

Quote
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.

Quote
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/

Quote
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).

Quote
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


Offline jzz

  • Neuling
  • *
  • Posts: 7
    • View Profile
Re: Our GrandOrgue users
« Reply #5 on: 20. October 2015, 17:12:24 »
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.

Offline martin

  • Jr. Mitglied
  • **
  • Posts: 78
    • View Profile
    • GrandOrgue

Offline jzz

  • Neuling
  • *
  • Posts: 7
    • View Profile
Re: Our GrandOrgue users
« Reply #7 on: 30. October 2015, 17:52:33 »
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

Offline oleg68

  • Neuling
  • *
  • Posts: 9
    • View Profile
Re: Our GrandOrgue users
« Reply #8 on: 14. February 2016, 07:46:43 »
  • 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.

Offline oleg68

  • Neuling
  • *
  • Posts: 9
    • View Profile
Re: Our GrandOrgue users
« Reply #9 on: 14. February 2016, 07:54:20 »
Quote
        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.

Offline martin

  • Jr. Mitglied
  • **
  • Posts: 78
    • View Profile
    • GrandOrgue
Re: Our GrandOrgue users
« Reply #10 on: 14. February 2016, 12:29:55 »
4. I use a gametable with three manual keyboards  an a pedalboard. Each one is connected directly throught USB.
As you are using multiple USB keyboards. There is GO prototyp that will keep the USB device mapping.without any further OS changes:
https://sourceforge.net/p/ourorgan/discussion/962125/thread/75284172/

https://patchwork.kernel.org/bundle/e9925248/provide%20sequencer%20sound%20card/

Offline martin

  • Jr. Mitglied
  • **
  • Posts: 78
    • View Profile
    • GrandOrgue
Re: Our GrandOrgue users
« Reply #11 on: 14. February 2016, 12:48:41 »
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.

Offline oleg68

  • Neuling
  • *
  • Posts: 9
    • View Profile
Re: Our GrandOrgue users
« Reply #12 on: 14. February 2016, 21:45:50 »
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?
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.

Offline oleg68

  • Neuling
  • *
  • Posts: 9
    • View Profile
Re: Our GrandOrgue users
« Reply #13 on: 14. February 2016, 22:02:55 »
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.

Offline martin

  • Jr. Mitglied
  • **
  • Posts: 78
    • View Profile
    • GrandOrgue
Re: Our GrandOrgue users
« Reply #14 on: 16. February 2016, 20:03:20 »
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, ....