GO 1471 error 6

[Ghekorg7 (Ret)]

Hi
I'm testing GO latest build 1471 x64 and getting this error messages which were not present on the same sets on 1437.


13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Can not wait for thread termination (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)
13/12/2013 10:14:05 πμ: Couldn't terminate thread (error 6: ο δείκτης χειρισμού δεν είναι έγκυρος.)

Any ideas what this error 6 is ?
What I have to do to cure ?
Is any other friend here experiencing this ?

 

[erikds]

Hello Panos,

I had the same error here.
In my case there was a "strange" new MIDI device that showed up in both input and output devices and was checked.
It is called here Organ-PC 8 for input and Organ-PC 9 for output, but there is no corresponding MIDI device.
Just unchecking this eliminated the error.
The "strange" MIDI devices are still shown under Audio/MIDI - MIDI Devices.
All the best.

Erik.

 

[Ghekorg7 (Ret)]

Hi Erik !
Thanks for the info, I'll try now and post back if it is the same here (most probably, as it seems to me logical now).

 

[Ghekorg7 (Ret)]

OK just tested

No work. No strange midi in/outs. I unchecked everything, checked again few of them, hit save, close re-open. The above error/messages continue to show up.
No affect of sound or functions or performance though. But it's annoying to see error messages and also not knowing from where they come and what to do to erase.

Main midi ins here

EMU xMidi 1x1 tab (midi to USB)
LoopMidi ports
Korg NanoKontrol Mk.I
Korg NanoKey Mk.I

What is that Thread which cannot be terminated ???

 

[astazou]

It's related to the new (still undocumented, WIP) "Load Concurrency" setting in the options tab, which is designed to quicken the uncached load.
Go to the Audio/Midi options, options tab and set the value to 0 (zero) to remove the error.

 

[erikds]

It's related to the new (still undocumented, WIP) "Load Concurrency" setting in the options tab, which is designed to quicken the uncached load.
Go to the Audio/Midi options, options tab and set the value to 0 (zero) to remove the error.

Thanks for the info.
Setting this new parameter to 0 indeed eliminates the error 6 message.


@ Panos
Sorry for my premature conclusion.
When I loaded your Schnitger 1720 for the first time in GO 1471 i got the error 6 but also the warning "Cache file had different hash bypassing cache".
So apparently when loading a disposition for the first time in a new GO version, the previously existing cache file is rejected.
I erroneously believed that removing the check mark on the "strange MIDI input and output" cured the problem, because i loaded the same disposition a second time, and obviously this was from the freshly made cache, and did not have error 6.
But after your message I loaded a different disposition for the first time in GO 1471 and sure enough the error 6 was there again.
So the message from astazou explains fully what i have experienced.

Maybe Martin can use this info, and perhaps tell us what this new parameter is all about and how we have to use it to avoid error messages.

All the best.

Erik.

 

[Ghekorg7 (Ret)]

GREAT !
Astazou you gave the answer and solution to elimante error 6. Indeed Release concurency to zero = no error 6.
It was on 8 (I have a i7 3630QM here) ....

Erik still thank you for fast replies ! Yes I also forgot to tell you that I loaded 3 different organs and it was there on all of them. So this was the right thing to do over there to find out.

Yep , GO devs can put some light here. And invho it would be nice to see somewhere what's new on each new test version of 0.3.1 so we will know where to look and for which purpose or so. A text file with all updates/changes/improvements in the main folder ?

Anyway it works now super, not complaining, but we have to know what is this new feature and how we can use it and everything better that brings to us.


PS @ ERIK : so glad you 're using "my" Schnitger 1720.... ;-)

 

[e9925248]

Astazou you gave the answer and solution to elimante error 6. Indeed Release concurency to zero = no error 6.
It was on 8 (I have a i7 3630QM here) ....

Are you sure, that it has been "Release concurrency"? It should have no zero option and this setting has not been changed.

Judging from the post, load concurrency is causing "error" message on Windows.
I'll look into it.

 

[Ghekorg7 (Ret)]

Hi again,
SORRY ...my typo ! Astazou posted Load concurrency.... which is the correct !!!! Release is wrong as of course has no zero setting !!

Accept my deep apologies for this serious typo on a serious matter. :-( :-(

So, setting Load Concurrency to zero eliminates error 6, as Astazou posted.

 

[e9925248]

So, setting Load Concurrency to zero eliminates error 6, as Astazou posted.

These messages should be ignored and will be removed in the future.

Apart from the error messages, how does Load Concurrency affects the non-cache load time?

 

[erikds]

Apart from the error messages, how does Load Concurrency affects the non-cache load time?

I can do some testing to answer your question.
I run an older Intel Q6600 quadcore PC with 8 GB Ram under Windows 7 64 bit.
But i think relevant info can be obtained quicker if you first indicate some values for the parameter Load Concurrency that are adviseable in my case.

All the best.

Erik.

 

[e9925248]

I run an older Intel Q6600 quadcore PC with 8 GB Ram under Windows 7 64 bit.
But i think relevant info can be obtained quicker if you first indicate some values for the parameter Load Concurrency that are adviseable in my case.

I would start with the number of cores. This will try to utilize all cores during loading. Part of the time, the thread will be waiting for disk, so the CPU should be able to handle higher number.
The big question is, if your IO subsystem (=harddisk) can keep handle the higher read load optimally or if it gets slower because of too much load.

Don't forget, that you need to test the load without any cache.

 

[erikds]

OK i shall do some tests and report.
I take it that loading a sample set with Audio/Midi-Automatically manage cache not checked will load the sample set without making a cache file.
Is this correct?

By the way is there a method to find which .cache file or .cmb file belongs to which sample set?

All the best.

Erik.

 

[Ghekorg7 (Ret)]

Hi again,

I'm running 1471 on windows 8 x64 with i7 IvyBridge 3630QM @2.4GHz (up to 3.2GHz turbo) 16GB (up to 24GB) ram and two discs Samsung SSD 128GB Sata HDD 700GB.
1471 after installation had set concurrencies at 8. Intel 3630QM has 4 cores 8CPU with hyperthread.
GO is installed in SSD (C) program files x64
MyOrgans are in Sata HDD (E)

I'm not seein' much difference setting concurrency at 4 or 8 Everything loads very fast here, faster if I "put" a sample set in the SSD. Not much of cache use here, expept in a coupla big sets where indeed it helps loading. The higher time (Laurenskerk Marcussen) is about 2:34 minutes with cache.
In fact doin some tests on load time with the same sample set released for HW4 and having it for GO 0.3.1.x too (full fx and releases), in GO loads much faster !
I'm keeping Load concurrency at zero.
Release concurrency has settings 1~7. No 0 or 8.

Also loading all my sets with no Lossless compression on, at 24/48000 all loops all releases at 128 buffers with Asio4all driver to RealTek on board soundcard 6.0.1.6744 DirectX 11.0 HDAudio ALC269.

As GO data are so far, I can see which cmb is for which set by reading it with notepad++ The cache file has the same numbers. This is kinda PITA to know which witch is which and these long numbers should have something relative to the sample set to identify ?

So, please Martin tell me what to do to run some tests as you want them, now that you know my system. Example settings ect

 

[L.Palo]

Please do note that you're not "supposed" to manage the .cmb and .cache files manually in the file system. It should be done through GO itself. The only exception is .cmb files that you have exported yourself, but then you'll have named it to something yourself and saved to a location you have chosen.

@Panos: You shouldn't really notice much difference between 4 or 8 since you have 4 real cores (the hyperthreading only creates virtual cores but the real ones will anyway have to do the work of the virtual ones). By the way, you've done a nice computer upgrade!

Kind regards

Lars P

 

[L.Palo]

And invho it would be nice to see somewhere what's new on each new test version of 0.3.1 so we will know where to look and for which purpose or so. A text file with all updates/changes/improvements in the main folder ?

All changes between revision numbers are available on the GrandOrgue Sourceforge page under the menu item Svn, just browse through it to find short descriptions of what's new with every revision. As GO is not a commercial application the development model is a rather "continous improvement" one and many changes are not immediately visible to the end user but anyway needed for the future development.

Kind regards

Lars P

 

[erikds]

Apart from the error messages, how does Load Concurrency affects the non-cache load time?

Hello Martin,

As promised hereafter results of some brief testing on the PC as described before:

I loaded a sample set that fills up memory to about 7 GB (including Windows 7 and GO 1471)

LC Load time min:sec

0 3:05
2 1:33
4 1:12
8 1:16
12 1:14

So your assumption that best results are obtained by setting LC equal to number of physical cores seems confirmed here.

The above load times are all with Lossless Compression, Compress cache and Automatically Manage cache not enabled.

All the best.

Erik.

 

[e9925248]

I take it that loading a sample set with Audio/Midi-Automatically manage cache not checked will load the sample set without making a cache file.
Is this correct?

Yes. GO only redo cache files, if either automatic management is on or you select "update cache".
GO will use the cache during loading, if it finds a suitable version => any cache needs to be delete to stop GO from using it (File/Delete Cache)

By the way is there a method to find which .cache file or .cmb file belongs to which sample set?

The Cache/Data folder are not considered user-editable. To aid recovery [eg. from a backup], each cmb file still contains the ODF path.

 

[e9925248]

I'm not seein' much difference setting concurrency at 4 or 8 Everything loads very fast here, faster if I "put" a sample set in the SSD. Not much of cache use here, expept in a coupla big sets where indeed it helps loading. The higher time (Laurenskerk Marcussen) is about 2:34 minutes with cache.
In fact doin some tests on load time with the same sample set released for HW4 and having it for GO 0.3.1.x too (full fx and releases), in GO loads much faster !
I'm keeping Load concurrency at zero.
Release concurrency has settings 1~7. No 0 or 8.

Are you confusing settings again?

Relase + "normal" concurrency affect runtime performance / polyphony.

Load concurrency affects load time, if no valid cache is present. See erikds numbers.

PS: If you try to sequeeze as much data as possible into memory, you should set load concurrency to zero. Load concurrency in r1479+ should be more reliable in low memory situations.

 

[Ghekorg7 (Ret)]

Hey Lars !

I got all GO data folders in my HDD (E) to save space in my (C) ie SSD which is fast but only 128 GB AND windows are installed in this one too.
I think I 'll have to run these tests in my older win7 x64 Intel dual core T4400 2.2GHz 4GB ram to see if there is an improvement on loading speed.

Yep a good upgrade and it did cost me just 1200e back in July 2013. It is a Greek manufacturing brand named Turbo-x and this model was the top of the line.
Now as a new model it comes with Haswell i7 and 64GB ram..... LOL
To get a similar mainstream notebook would cost around 2000+ and as a Mac close to 3000e.
And yes 4 real cores, but task manager shows at all times 8 CPU performance (0-7) each on its own "green" window.
I'm enjoyin' GO with this lap loading BIG sets and hardly these 8 CPU move upwards. Only in big tuttis and staccato playin' I'm surpassing 5000 polyphony and i7 goes to 3.2GHz.
GO 1471 performs with no problems, only very occasionaly Marcussen set (5.2GB cache...) instead of 2:35 min load (from HDD at 5.200), does 3:05min = 30sec slower