I am testing the latest "deken" version of freeverb~ to see if an old issue regarding dividing by 0 was fixed.
years ago, freeverb~ would just continue to overload until the audio dropped, this was due to the fact that it processed 0 signal and created conflict (I found this out in an email thread years ago -can't find it now). the simple solution was to have freeverb~ always process a noise~ signal in extremely low amplitude.
the latest version in deken does not reach the point of overloading the CPU, but whenever it has 0 signal to process it still spikes the CPU usage.
I wanted to ask who was in charge of this object to see if there is interest in getting this fixed.
ps. it is very easy to reproduce, just use the example in the help file and watch the CPU usage while it has some signal to process and when it doesn't.
a small video to show the issue:
https://www.dropbox.com/s/e4g2ty142wx7h48/freeverb-desktop.m4v?dl=0
On 2016-07-25 10:00, José Rafael Subía Valdez wrote:
I wanted to ask who was in charge of this object to see if there is interest in getting this fixed.
afaik, nobody is in charge of the code. however, somebody is in charge for the deken package: the one who uploaded it.
the deken maintainers of a given package might show interest in getting bugs fixed, so contacting them is a good start.
when finding an external via deken, you will also be given the information who did the upload. in the case of freeverb~, this spits out chr15m, fjkraan and zmoelnig.
fgmasr IOhannes
On 2016-07-25 12:59 PM, IOhannes m zmoelnig wrote:
On 2016-07-25 10:00, José Rafael Subía Valdez wrote:
I wanted to ask who was in charge of this object to see if there is interest in getting this fixed.
afaik, nobody is in charge of the code. however, somebody is in charge for the deken package: the one who uploaded it.
In the version I uploaded, the issue might be fixed. From the README.txt:
Recent changes (1.2.2):
- fixed the NaN/denormal check,
- added functionality to allow filtering on the first delayed signal.
You might try this one to see your issue is fixed by this.
the deken maintainers of a given package might show interest in getting bugs fixed, so contacting them is a good start.
when finding an external via deken, you will also be given the information who did the upload. in the case of freeverb~, this spits out chr15m, fjkraan and zmoelnig.
fgmasr IOhannes
Greetings,
Fred Jan
Hi Fred, I've been working with IOhannes fixing some w32 Deken packages. We included some .dlls that were needed by some objects, mostly those that were compiled against pthread and other Libs. I've detected that pthreadGC2.dll is missing in your pkgs: cyclone-v0.2beta1-(Windows-i386-32)(Sources)-externals.zipmaxlib-v1.5.6-(Windows-i386-32)(Sources)-externals.zipmaxlib-v1.5.6-(Windows-i686-32)(Sources)-externals.zip The solution is simply to add pthreadGC2.dll in the same folder as the external. Not including it lead to “... couldn't create” on systems that do *not* have pd-extended installed. The procedure has been to include the .dll in each Pkg so that if needed Pd finds it, once loaded it will be used by other objects too. But is has to be there on each Pkg because is unknown which [object] will load it first. Can you update your Pkgs? Btw, they are great Pkgs. Salutti,Lucarda.
Mensaje telepatico asistido por maquinas.
Hi Lucas,
Hi Fred,
Can you update your Pkgs?
Yes, I will update them. Thanks for working it all out.
Btw, they are great Pkgs.
It is easy to make a package from already great software :-).
Salutti, Lucarda.
Greetings,
Fred Jan
Mensaje telepatico asistido por maquinas.
Hi all,
There are updated versions for maxlib and cyclone for Windows available via the deken tool. Both have pthreadGC2.dll included, but the cyclone/coll object also required libgcc_s_dw2-1.dll from the MinGW.
Greetings,
Fred Jan
Thanx Fred:
cyclone/coll object also required libgcc_s_dw2-1.dll from the MinGW.
Could you explain why "libgcc_s_dw2-1.dll " is needed?
I've become paranoid because that escape my tests, and there *could* be other Deken pkgs that need it.
I cant detect it with http://www.dependencywalker.com/ and couldn't detected just opening the help patch.
Does "libgcc_s_dw2-1.dll " is called only when a certain [coll] process is triggered ?
Any knowledge, thought, ideas are welcomed.
Salutti, Lucarda
Mensaje telepatico asistido por maquinas.
On 2016-07-30 12:07 AM, Lucas Cordiviola wrote:
Thanx Fred:
/>cyclone/coll object also required libgcc_s_dw2-1.dll from the MinGW/.Could you explain why “libgcc_s_dw2-1.dll “ is needed?
Not really. For proper testing you need a Windows machine that has no MinGW development kit installed, or at least not in the current PATH. Usually when a dll is missing the system shows a popup window stating the name of the dll. Here this often doesn't happen. It did once, so I knew the name of the dll.
I've become paranoid because that escape my tests, and there *could* be other Deken pkgs that need it.
I cant detect it with http://www.dependencywalker.com/ and couldn't detected just opening the help patch.
Does “libgcc_s_dw2-1.dll “ is called only when a certain [coll] process is triggered ?
The dependency on pthread.h / pthreadGC2.dll was introduced to make loading data sets into coll multi-threaded. Loading large data sets would cause drop-outs in the audio.
The threaded loading patch came from pd-L2ork and was proposed by Ivica Bukvic.
Any knowledge, thought, ideas are welcomed.
My knowledge on the Windows DLL-mechanism is quite limited, but apparently it is more dynamic than expected. In this specific case threading is used for file IO operations. But the object fails to load, so all DLLs are required at load time.
Somehow I assume the MinGW system has a provision to prevent this kind of issue. If the compiled binaries can only be run on machines having the build system installed, the use of MinGW would be quite limited. Time to read the documentation ;-).
At least the MinGW DLLs are licensed as Public Domain of MIT (depending on distribution) so redistribution is not an issue.
Salutti, Lucarda
Greetings,
Fred Jan
Mensaje telepatico asistido por maquinas.
Hi Fred,
First, Did you recompiled [coll] with changes from the previous pkg?
Attached image of previous and actual [coll] analyzed with http://www.dependencywalker.com/ http://www.dependencywalker.com/
If you did not recompiled with changes I have "troubles" and I'm just looking for them.
Not really. For proper testing you need a Windows machine that has no
MinGW development kit installed, or at least not in the current PATH.
Usually when a dll is missing the system shows a popup window stating
the name of the dll. Here this often doesn't happen. It did once, so I
knew the name of the dll.
Yes, I did my tests on a relatively clean machine (win 8.1) with a patch that open every help.pd in the pkg, there I get popups of missing.dll, place them and re-tested the pkg again, closing and reopening pd for each pkg test (.dlls remain loaded if not closing pd).
This type of test can not be done in win10, this Os does not popup missing .dll and it does not report it in the "event viewer" at least not for Pd.
Other few pkgs were tested only with DependancyWalker, i.e iemmatrix.
Please don't get me wrong, I'm not saying that "libgcc_s_dw2-1.dll" is not needed, I want to know why I have not detected it in the previous pkg, and transfer this possible "problem" to other pkgs.
Again, did you recompile [coll]?
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Hi Lucas,
Hi Fred,
First, Did you recompiled [coll] with changes from the previous pkg?
Yes, I did recompile the package because I wanted the copying of the DLLs being part of the Makefile (while executing 'make install'). And there were some minor changes, but not enough to build for all platforms, IMHO. The coll sources are unchanged.
So far I found the problem is not caused by a newer version of the build system; an older version also produces the dependency on libgcc_s_dw2-1.dll. Another possibility is that it is caused by an upgrade of MinGW/MSys. I hope to have some time soon to check this out.
It would be nice if the build system could report these dependencies or even take care of them. But this will not be realized in the short term.
Greetings,
Fred Jan
Attached image of previous and actual [coll] analyzed with http://www.dependencywalker.com/ <http://www.dependencywalker.com/ >
If you did not recompiled with changes I have “troubles” and I'm just looking for them.
/> Not really. For proper testing you need a Windows machine that has no / /> MinGW development kit installed, or at least not in the current PATH. / /> Usually when a dll is missing the system shows a popup window stating / /> the name of the dll. Here this often doesn't happen. It did once, so I / /> knew the name of the dll. /Yes, I did my tests on a relatively clean machine (win 8.1) with a patch that open every help.pd in the pkg, there I get popups of missing.dll, place them and re-tested the pkg again, closing and reopening pd for each pkg test (.dlls remain loaded if not closing pd).
This type of test can not be done in win10, this Os does not popup missing .dll and it does not report it in the “event viewer” at least not for Pd.
Other few pkgs were tested only with DependancyWalker, i.e iemmatrix.
Please don't get me wrong, I'm not saying that “libgcc_s_dw2-1.dll” is not needed, I want to know why I have not detected it in the previous pkg, and transfer this possible “problem” to other pkgs.
Again, did you recompile [coll]?
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Hi Fred, thanx a lot for all info.
So far I found the problem is not caused by a newer version of the build
system; an older version also produces the dependency on libgcc_s_dw2-1.dll.
Another possibility is that it is caused by an upgrade of MinGW/MSys. I
hope to have some time soon to check this out.
I am pretty sure that libgcc_s_dw2-1 is not needed in the previous pkg. I`m still testing and everything works, even [coll a.txt 1].
Also binary comparing both coll.dll returns differences, which surely explains the hole thing.
Anyway everything is Ok, as the actual pkg is fully operational, also as you are taking *good care* of other pkgs you are already aware of the w32 dep things.
It would be nice if the build system could report these dependencies or
even take care of them. But this will not be realized in the short term.
Sure, one work around is to use DependancyWalker on a clean or virtual machine or also Pd on a clean/vm with an <= win 8.1 Os.
Since my primary concern was avoiding to have undetected .DLLs on my previous pkg tests I think that the recompiling of [coll] explains that confusion.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
howdy, I noticed the new windows version for cyclone is 0.2beta2, while the other systems are 0.2beta1 (which does not exist anymore for windows) - I guess this might be a little confusing, it might give the impression that the windows version has more features and updates, while they seem to be the same.
So i dont know, but maybe a suggestion would be change/rename the other system's version to beta2 as well?
cheers
2016-07-29 19:07 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
Thanx Fred:
*>cyclone/coll object also required libgcc_s_dw2-1.dll from the MinGW*.
Could you explain why “libgcc_s_dw2-1.dll “ is needed?
I've become paranoid because that escape my tests, and there *could* be other Deken pkgs that need it.
I cant detect it with http://www.dependencywalker.com/ and couldn't detected just opening the help patch.
Does “libgcc_s_dw2-1.dll “ is called only when a certain [coll] process is triggered ?
Any knowledge, thought, ideas are welcomed.
Salutti, Lucarda
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks for responding Fred,
it is better as it does not go up to a point of breaking everything but there is still a spike as you can see in the video.
anyway, thanks for the info.
On Mon, Jul 25, 2016 at 4:50 PM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
On 2016-07-25 12:59 PM, IOhannes m zmoelnig wrote:
On 2016-07-25 10:00, José Rafael Subía Valdez wrote:
I wanted to ask who was in charge of this object to see if there is interest in getting this fixed.
afaik, nobody is in charge of the code. however, somebody is in charge for the deken package: the one who uploaded it.
In the version I uploaded, the issue might be fixed. From the README.txt:
Recent changes (1.2.2):
- fixed the NaN/denormal check,
- added functionality to allow filtering on the first delayed signal.
You might try this one to see your issue is fixed by this.
the deken maintainers of a given package might show interest in getting bugs fixed, so contacting them is a good start.
when finding an external via deken, you will also be given the information who did the upload. in the case of freeverb~, this spits out chr15m, fjkraan and zmoelnig.
fgmasr IOhannes
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-07-25 11:53 PM, José Rafael Subía Valdez wrote:
Thanks for responding Fred,
it is better as it does not go up to a point of breaking everything but there is still a spike as you can see in the video.
The video doesn't work for me (it did once, but now the Flash/dropbox overhead appears to be too much). Can you just post a test patch?
Running freeverb~ only results in a load of about 6% on my +3 year old PC, so some data on your enviroment is also welcome.
-- José Rafael Subía Valdez www.jrsv.net http://www.jrsv.net
Greetings,
Fred Jan
-
Alexandre Torres Porres -
Fred Jan Kraan -
IOhannes m zmoelnig -
José Rafael Subía Valdez -
Lucas Cordiviola