• Welcome to the Pipe Organ Forum! This is a part of the open community Magle International Music Forums focused on pipe organs (also known as "church organs"), organists, organ music and related topics.

    This forum is intended to be a friendly place where technically advanced organists and beginners (or even non-organists) can feel comfortable having discussions and asking questions. We learn by reading and asking questions, and it is hoped that the beginners (or non-organists) will feel free to ask even the simplest questions, and that the more advanced organists will patiently answer these questions. On the other hand, we encourage complex, technical discussions of technique, music, organ-building, etc. The opinions and observations of a diverse group of people from around the world should prove to be interesting and stimulating to all of us.

    As pipe organ discussions can sometimes become lively, it should be pointed out that this is an open forum. Statements made here are the opinion of the poster, and not necessarily that of the forum itself, its administrator, or its moderators.

    In order to post a new topic - or reply to existing ones - you may join and become a member by clicking on Register New User. It's completely free and only requires a working email address (in order to confirm your registration - it will never be given away!). We strive to make this a friendly and informative forum for anyone interested in pipe organs and organ music.

    (Note: If you wish to link to and promote your own website please read this thread first.)

    Many kind regards
    smile.gif

    Frederik Magle
    Administrator

    Krummhorn
    Co-Administrator

GO 0306 1086 to 1087 what's new ?

scush

New member
I beleive if the installer was to delete the grandorgue registry key it would prevent many problems.

john
 

scush

New member
I apologize for all these posts.
The hanging at closure of GO,was Rt/asio.
It is ok with PA/asio.(on my machine anyway)
john
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
[....3) Has the cache been updated/created?
In that case, GO will only read the ODF + the cache file.
The cache files will be put in the GO cache directory (see GO settings).]

Let me see this, Martin and I'll post asap. I think I missed something to check/test or learn here. Thanks for pointing out.
I think I'm updating on each load..... :-/

@John : PA/Asio also here :) No issues.
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
OK. Cache.

Mea culpa.....

I didn't update, so everytime set loading as fresh....

Tested with a smaller 9stop custom organ (Francis Chapelet style 1.26GB) at 24/48000 all loops, releases , attacks, losseless on.
Memory allocation 953MB.

Loading first time took 2min 50sec, Updating (actually writing/creating, yes) cache took 3min 23sec.
Close GO.
Re-open, load set : 59 sec !!!!!! (high speed...)

This speed has a serious cost though (as with HW....) Cache file on User/App/Roaming/GrandOrgueData is now 833MB (...), ie almost 1GB minus of my free HDD space. And this has a serious meaning if one needs many sets on his OS. Almost 2/3. This set is now 1.26GB + 833MB = 2093MB.
Imagine how these numbers increase as bigger the sets are (my custom V2 big is 6.58GB... allocation close to3.6 ... and with cache created will be close to 11GB and 180MB !).

So, I believe the solution is to use cache for the most often in use and big and personal sets and leave it for the rest. Or use external HDD for the samples and odf folders and leave on board the Cache load weight :).... or... Get a computer with Terras.... LOL

Nevertheless, I must thank (again...) Martin for clarifying this Cache theme on GO 0306, when in use speeds up loads and make faster all preparations for playing the set.
 

scush

New member
@Panos
Using the new features in win7 taskmanager I discovered that when memmory use is high.
GO was reading from the pagefile (direct from disk) also it was reading from the cache.
This caused the sound to breakup,so I deleted the cache and disabled the pagefile.
Also with compression enabled I only about get half the polyphony that I do without it.

john
 

e9925248

New member
Loading first time took 2min 50sec, Updating (actually writing/creating, yes) cache took 3min 23sec.
Close GO.
Re-open, load set : 59 sec !!!!!! (high speed...)

This speed has a serious cost though (as with HW....) Cache file on User/App/Roaming/GrandOrgueData is now 833MB (...), ie almost 1GB minus of my free HDD space. And this has a serious meaning if one needs many sets on his OS. Almost 2/3. This set is now 1.26GB + 833MB = 2093MB.
Imagine how these numbers increase as bigger the sets are (my custom V2 big is 6.58GB... allocation close to3.6 ... and with cache created will be close to 11GB and 180MB !).

Disk space is in TB regions today.

Could you please retest with an uncompressed cache too [Disable "compress cache" in the GO settings, run "update cache" and load the organ]?
 

wehtam721

New member
Another comment on disk space... I had thought the same thing as Panos. Using the cache is faster, but nearly doubles the size the organ takes up on the hard drive. I came up with a best of both worlds scenario. At least on my setup, I can create the cache and then remove all of the original .wav sound files to an external drive (of course I would never permanently delete them). This leaves the user with only the smaller cache on their primary hard drive. My organ loads and plays without a problem if I do this. If I need to update the cache, I just temporarily copy the files back off my external drive onto the hard drive of my computer again. This might be a viable workaround for some, especially if you already have an external hard drive. If not, most sets would fit onto a reasonably sized flash drive just as well then you could just keep them stored in a desk drawer.

I don't know if there are any potential complications with this method, but, if so, it seems to have not been a problem for me thus far.

Take care,
Matt
 

e9925248

New member
I don't know if there are any potential complications with this method, but, if so, it seems to have not been a problem for me thus far.
I don't see any complications - it just requires lots of effort, because after many kind of changes the cache needs to rebuilt.

The recommended setup is to keep the samples on a (slow) disk always accessible, while the cache is stored on a faster disk.
 

L.Palo

New member
Hi!

This is mostly in reply/comment to #14.

I dusted off the only computer I have that uses Windows 7 (64 bit) as OS and tried the installer http://sourceforge.net/projects/our...ble)/GrandOrgue-0.3.0.61088-wi64.exe/download for the first time. (Remember that I normally use Linux and build from source myself...)

Installation worked fine except that the files were placed in C:\Program Files (x86) even though this should be a 64 bit build, right? It should be installed in C:\Program then instead.

Translations worked fine, again with the exception that it seems that not all the wx built-in translations are linked with the build. (visible in some dialogs)

Another irritating thing was that Windows didn't like the installer file when I downloaded it. It complained that it was an untrusted file that's potentially dangerous. (lot's of blah blah, I certainly trust JLD to not distribute something dangerous knowingly...) The same when actually trying to perform the install. (Not a signed software). I don't know if there's anything we can do about it but it would certainly look better for a new user if one didn't have to wrestle so much with Windows just to install the software.

Anyway, many thanks for the continual effort to spread GO to a wider audience!

Kind regards

Lars P
 

e9925248

New member
Installation worked fine except that the files were placed in C:\Program Files (x86) even though this should be a 64 bit build, right? It should be installed in C:\Program then instead.
The current installer is 32bit - it does not know, what kind of programs it installs.

Translations worked fine, again with the exception that it seems that not all the wx built-in translations are linked with the build. (visible in some dialogs)
Could you check for wxstd.mo files somewhere in the GO program directories? If not, the installer creator didn't run the command to built the wxWidgets translations [cd locale && make allmo - cmake needs to rerun too].

It complained that it was an untrusted file that's potentially dangerous.
The installer has not been signed. To change the warning in the IE, somebody need to get a commerical code signing certificate from a trusted CA and sign the installer with it (http://stackoverflow.com/questions/252226/signing-a-windows-exe-file).
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
Hi,

Lots of posts after my last visit ! :-D LOL

OK

@ Martin - TB yes, it is the standard but not for all GO users, as 64bit is the standard, especially for VPO, but there are many 32bit out there too...
Yep, I'll test as you ask, but not sooner than one day or two. I'll post results here.

@ Matt - Yeah, the same method, but with the difference Martin describes : Fast HDD for cache (I have a Maxtor 200GB at 7.200 rpm) and slow for samples (Sata 500GB at 5.900rpm). On main laptop I got GO and two of my custom organs (HD 280GB 5.900rpm).
I see now on our Turbo-x brand in Athens the hybrid ones on laptops with a SSD & HDD in one. So One can install GO and cache on SSD and samples on HDD.
Good performance.

@Lars - Early on win7 I shut down my UA and got rid of warnings on which software is confirmed or not ect ect :) Also UA gave me hard times on installing my precious East West Quantum Leap Symphonic Orchestra (how suspicious and bad can be !!!??), simply not allowing any installation ! Midi yoke and many other useful apps get stopped by UA... Shut it down !
Yep I already posted too about the x64 installer pre-set to install GO on x86 files... Lucky it has a change destination option :)

Anyway, whatever the issues we're talkin' here, they do not affect GO 0306's 1087, now 1088, performance and its class now as one of the top Pipe Organ simulators. As I posted elsewhere I can play GO 0306 on a netbook 10' x64 win7 2GB ram and just a single core older Intel Celeron 1.3GHz ! No cracks at all. Just pure sound and joy.

Cheers
Panos
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
@ JLD

Hey, I managed to test 1088 x86 on a friends laptop with windows vista home SP2 32bit, Intel Core Duo T7300 at 1.80 GHz and 1GB ram.

Installs OK, attributes .organ files automatically (I did nothing - never before any GO version on this lap).

The main issue was the cracked sound.... I had to increase buffers to 630 (!) to get a clean sound. Asio4all, Asio4all (PA) , DS. So there was latency.
No way to use 128, 256 or even 512 !

Set loaded : Romansvillier GO2 version. Allocated 199MB or so at 16/44100, losseless on, compressed cache. Concurrency 2. RealTek soundcard on board.

This is possibly because of the low Ram (1GB) from which this lap used 680MB for system and opened programs. There wasn't many to close with Task manager to lower this figure. Went to 600MB. So...

Also the low rate 1.80GHz for a CoreDuo maybe plays its role on this low performance of this specific HP Pavillon entertainment lap.

But 1088 went OK :)
 

e9925248

New member
Hey, I managed to test 1088 x86 on a friends laptop with windows vista home SP2 32bit, Intel Core Duo T7300 at 1.80 GHz and 1GB ram.

Set loaded : Romansvillier GO2 version. Allocated 199MB or so at 16/44100, losseless on, compressed cache. Concurrency 2. RealTek soundcard on board.

Is Hyperthreading on or off?
Concurrency 2 with 2 cores with hyperthreading on could yield to less preformance, as any OS could schedule the two threads on only one processor, while the resources of the second processor are not used.
 

scush

New member
The issue here is probably the realteck driver.
The problems concerning high lattency are widely reported on the internet.
People are seeking out different versions of the driver,hopeing to improve performace.
I have realteck onboard sound, I was running win xp 32.
The lowest buffer setting possible was 832 samples.
Even at this I then had to go into the asio4all control panel
and adjust the hardware buffer slider adding even more to find the sweetspot.
I then installed win7 64 on the same machine.
now buffersize of 128 is possible but 256 is more stable.
john
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
Hi e, Scush :)

Hyperthread off..... I'm affraid. When I'll get my hands again on this lap I'll test again with On. :-/

RealTek.... I have two working here :
both win 7 64bit.

Main lap with Intel T4400 2.2GHz 4096MB ram Sata 5.900rpm 280GB. It is set at 24/48000 and I'm playing big organs (custom) with 3.5GB allocated memory and 128/48000 concurrency 2 and GO reads 6ms latency. And it is so as the sound is just great.

The other one is a surprise : my son's netbook 10' win7 64bit Intel Celeron 1.3GHz single core 2048MB ram Sata 5.200rpm and 250GB. Here main setting is 256/44100, though it plays smaller organs at 24/48000 with 6ms and great sound.

In both cases Asio4all is on.

I like the RealTek here as it causes no problems. Though I didn't test it on a 32bit machine so far until this Vista HP I posted.
My older (now off) HP win7 32bit lap had AMD Athlon 64 x2 at 2.2GHz and IDT soundcard. Here GO v02 had a great time, as all were 32bit and set at 16/44100.

Possibly RealTek plays better on 64bit ?
 

scush

New member
Hi Panos
Even now at 64 bit I have minor issues.
If asio is not used the sound gradualy goes distorted after about 15 minuets.
This can be corrected by pressing the midi panic/reset buton,or if left becomes clear again.
As though something is not synchronized.

If ASIO without the (PA) is used GO can freeze on applying settings or on closure.
Do you have any of these issues.
john.
 

Ghekorg7 (Ret)

Rear Admiral Appassionata (Ret)
Hi John,

No, no issues like that. I'm using Asio4all (v2.10 not the latest 2.11beta) without (PA). I must say I'm very happy with my main lap's performance with GO 0306.1088 x64. As was with 1026, 1086 & 1087.

On that Vista x86 lap I had to use Asio(PA) to get clean sound though. But then again, hyperthread was off.

The only time I got freezing and needed to re-boot was with Martin's early first 03 x64 build (without Asio) which was stopped from happening after one or two updates later.
On closure I had just one freeze (see relevant post) but was momentary (not repeated) as Anti-malware was downloading updates (forgot to close internet during that session...), so there wasn't any GO malfunction.
Panos
 

scush

New member
hi Panos

Thanks for the info.
There seem to be many versions of the realtek hd sound.
looks like I drew the short straw.
thanks john
 
Top