please apologize if this is not the right list to report problems with pd-extended.
i have just tried pd extended on windows, and encountered the following problems: -iem abs vcf_hp2,4,6,8 are missing (i copied these from my linux installation) -iem_cot missing, used by vcf_hp2 and vcf_lp2 (i changed that to cot4 in the abs and it seemd to work fine). this was probably also the cause of the problems i had with a nightly build of pd extended a while ago under linux. -library path are not set by default/by the installer? -the crashes when closing complex patches seem to happen more often compared to the linux version.
though it looks like this does not do any harm. -pdp is not included? -there is something strange with the cpu-load display. my patch which is the most heavy on the cpu, gets about 49 percent on my linux machine (dualcore athlon 3800+), but on my wintel laptop (singlecore pentium m, 1,6 ghz) it jumps between 7,9,23 percent.
apart from that, all of my patches i have tried worked fine (excluding the ones relying on pdp).
bis denn! martin
Thanks for the bug report, comments inline:
On Jun 13, 2007, at 4:44 PM, martin brinkmann wrote:
please apologize if this is not the right list to report problems with pd-extended.
i have just tried pd extended on windows, and encountered the following problems: -iem abs vcf_hp2,4,6,8 are missing (i copied these from my linux installation)
Found the bug in the install target of the Makefile, should be fixed
in the next release.
-iem_cot missing, used by vcf_hp2 and vcf_lp2 (i changed that to
cot4 in the abs and it seemd to work fine). this was probably also the cause of the problems i had with a nightly build of pd extended a while ago under linux.
"iem_cot~" seems to be an alias for "iem_cot4~". In general, aliases
are not currently supported in Pd-extended.
-library path are not set by default/by the installer?
The README tells you how to set this up. It should be done by the
installer in the next version.
-the crashes when closing complex patches seem to happen more often compared to the linux version.
If you can narrow this down, please post a bug report, hopefully with
a example patch, to the bug tracker:
http://puredata.org/dev/bugtracker
- sometimes pd throws a 'SIMD' message on the console.
though it looks like this does not do any harm.
I think it's from Gem.
-pdp is not included?
PDP has not been ported to Windows, perhaps you would like to do it? =D
-there is something strange with the cpu-load display. my patch which is the most heavy on the cpu, gets about 49 percent on my linux machine (dualcore athlon 3800+), but on my wintel laptop (singlecore pentium m, 1,6 ghz) it jumps between 7,9,23 percent.
If you have patch that illustrates this, that would be very helpful.
Please file a bug report if you make such a patch and attach it.
.hc
apart from that, all of my patches i have tried worked fine (excluding the ones relying on pdp).
bis denn! martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
-the crashes when closing complex patches seem to happen more often compared to the linux version.
If you can narrow this down, please post a bug report, hopefully with a example patch, to the bug tracker:
maybe it is just not true that the 'crash on windowclose' happens all the time under windows: right after writing my last mail i had a series of such crashes under linux, and today i can only reproduce this behaviour under windows whe i change something in a relatively big patch. load my 'groovebox1'-patch, remove/and re-add a connection, close the window, and pd crashes. (on a samsung x10 laptop running winxp sp2).
- sometimes pd throws a 'SIMD' message on the console.
though it looks like this does not do any harm.
I think it's from Gem.
i had this messages also before i discovered the .reg file for setting the path-defaults. and gem was not loaded.
PDP has not been ported to Windows,
that explains why it is not there.
perhaps you would like to do it? =D
maybe later this century. ;)
-there is something strange with the cpu-load display. my patch which is the most heavy on the cpu, gets about 49 percent on my linux machine (dualcore athlon 3800+), but on my wintel laptop (singlecore pentium m, 1,6 ghz) it jumps between 7,9,23 percent.
If you have patch that illustrates this, that would be very helpful.
Please file a bug report if you make such a patch and attach it.
it happens with all patches. on my (faster(?)) linux-box the (displayed) cpu-load is about 1.5 times higher, and stays relatively stable at this value, while on the windows-laptop it constantly changes between lower and higher values, but the average is clearly lower than the value on linux. maybe i should build something to max out the cpu to see which computer is really faster...
bis denn! martin
On 14/06/2007, at 21.23, martin brinkmann wrote:
Hans-Christoph Steiner wrote:
-the crashes when closing complex patches seem to happen more often compared to the linux version.
If you can narrow this down, please post a bug report, hopefully
with a example patch, to the bug tracker:maybe it is just not true that the 'crash on windowclose' happens all the time under windows: right after writing my last mail i had a series of such crashes under linux, and today i can only reproduce this behaviour under windows whe i change something in a relatively big patch. load my 'groovebox1'-patch, remove/and re-add a connection, close the window, and pd crashes. (on a samsung x10 laptop running winxp sp2).
Isn't this much like what you/we talked about late november last year
wrt. your groovbox patch? This rings a bell that's why, please check
if it's related to this bug report, which, i think, boils your
problem from last year down to a simple example:
<http://sourceforge.net/tracker/index.php? func=detail&aid=1607030&group_id=55736&atid=478070>
Steffen wrote:
Isn't this much like what you/we talked about late november last year wrt. your groovbox patch? This rings a bell that's why, please check if it's related to this bug report, which, i think, boils your problem from last year down to a simple example:
http://sourceforge.net/tracker/index.php?func=detail&aid=1607030&group_id=55736&atid=478070
yes, i belive it is somehow related, but it happens also when the subpatch is not open.
bis denn! martin