I have a laptop running Windows Vista Home Premium 64 bit. The machine is a dual-core Turion64 X2 with 4 GB of RAM. I installed the pd-extended Windows package from "puredata.info". It started up fine, but when I went into the "Media" menu and tried the test sine wave tone, it played, but it was not a steady tone -- it "warbled". I'm guessing there's some other "service" running that's competing with Pure Data for the sound card. Does anyone here have any ideas what I should look for? This is an HP Pavilion dv4 with a whole bunch of HP Multimedia software installed. I haven't tried uninstalling any of that yet.
Meanwhile, pd-extended runs just fine on another (32-bit) laptop with Ubuntu Intrepid Ibex. So I'm not down for the count, but I'd really prefer running under Windows if I can.
I've been doing a lot of dynamic patching and notice that using abstractions slows down the process immensely.
Why is it that test-abs.pd is so much slower than test-sp.pd (which just creates chains of internal objects in a subpatch)?
Is there any way this could be sped up in future versions of pd? I find dynamic patching to be a powerful idiom when used with abstractions, but its kind of clunky right now because of the lengthy creation time.
Thanks, Jonathan
p.s. please excuse the trivial nature of the dsp, which is just there for the sake of comparison
Hi,
Jonathan Wilkes wrote:
I've been doing a lot of dynamic patching and notice that using abstractions slows down the process immensely.
That's because Pd tries to load the abstraction from everywhere in its -path (which can be a large number of places), then parses the text and uses it to create obects - all of this EVERY time it is instanced.
Why is it that test-abs.pd is so much slower than test-sp.pd (which just creates chains of internal objects in a subpatch)? Is there any way this could be sped up in future versions of pd? I find dynamic patching to be a powerful idiom when used with abstractions, but its kind of clunky right now because of the lengthy creation time.
A quick and dirty attempt at caching abstractions in memory:
http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html
Also, I haven't checked the patches you attached, I hope you're turning dsp off before doing the dynamic patching and turning it on again (if desired) afterwards, otherwise the dsp graph is rebuilt after every object instead of just once (as far as I understand it).
Claude
--- On Tue, 5/12/09, Claude Heiland-Allen claudiusmaximus@goto10.org wrote:
From: Claude Heiland-Allen claudiusmaximus@goto10.org Subject: Re: [PD] Abstraction load time To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Tuesday, May 12, 2009, 12:39 PM Hi,
Jonathan Wilkes wrote:
I've been doing a lot of dynamic patching andnotice that using abstractions slows down the process immensely.
That's because Pd tries to load the abstraction from everywhere in its -path (which can be a large number of places), then parses the text and uses it to create obects - all of this EVERY time it is instanced.
Why is it that test-abs.pd is so much slower thantest-sp.pd (which just creates chains of internal objects in a subpatch)?
Is there any way this could be sped up in futureversions of pd? I find dynamic patching to be a powerful idiom when used with abstractions, but its kind of clunky right now because of the lengthy creation time.
A quick and dirty attempt at caching abstractions in memory:
http://lists.puredata.info/pipermail/pd-dev/2008-10/012334.html
Ah, that answers my question. Thanks for the explanation and link. Does the solution you came up with affect the load time of abstractions that are created after the patch has already been loaded?
Also, I haven't checked the patches you attached, I hope you're turning dsp off before doing the dynamic patching and turning it on again (if desired) afterwards, otherwise the dsp graph is rebuilt after every object instead of just once (as far as I understand it).
Oops, I didn't turn dsp off. Checking it now, it does increase load time a bit, though not nearly as much as using an abstraction instead of a chain of internal objects.
Thanks, Jonathan
Claude -- http://claudiusmaximus.goto10.org
it behaves like the opposite on my machine. the abstraction based patch measures 6ms and the one, that generates everything from scratch, measures ~300ms.
now, after claude's explanation, i think, i know why this is the case. i don't have any pathes loaded at all in my preferences. i try to do everything with [declare]s inside the patches. thus pd hasn't to search a whole bunch of pathes, but only the ones that are really useful.
roman
On Mon, 2009-05-11 at 19:49 -0700, Jonathan Wilkes wrote:
I've been doing a lot of dynamic patching and notice that using abstractions slows down the process immensely. Why is it that test-abs.pd is so much slower than test-sp.pd (which just creates chains of internal objects in a subpatch)? Is there any way this could be sped up in future versions of pd? I find dynamic patching to be a powerful idiom when used with abstractions, but its kind of clunky right now because of the lengthy creation time.
Thanks, Jonathan
p.s. please excuse the trivial nature of the dsp, which is just there for the sake of comparison
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
--- On Tue, 5/12/09, Roman Haefeli reduzierer@yahoo.de wrote:
From: Roman Haefeli reduzierer@yahoo.de Subject: Re: [PD] Abstraction load time To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Tuesday, May 12, 2009, 9:39 PM it behaves like the opposite on my machine. the abstraction based patch measures 6ms and the one, that generates everything from scratch, measures ~300ms.
now, after claude's explanation, i think, i know why this is the case. i don't have any pathes loaded at all in my preferences. i try to do everything with [declare]s inside the patches. thus pd hasn't to search a whole bunch of pathes, but only the ones that are really useful.
roman
Hi Roman, Ok, after clearing out all the path and startup info under the "file" menu, my load times for the abstraction based patch have decreased by an order of magnitude. But now I'm puzzled because my results are the reverse of yours: test-abs.pd takes around 250ms and test-sp.pd takes 6ms.
Are there any other preferences you alter to restrict the paths that are searched?
-Jonathan
On Tue, 2009-05-12 at 14:31 -0700, Jonathan Wilkes wrote:
--- On Tue, 5/12/09, Roman Haefeli reduzierer@yahoo.de wrote:
From: Roman Haefeli reduzierer@yahoo.de Subject: Re: [PD] Abstraction load time To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Tuesday, May 12, 2009, 9:39 PM it behaves like the opposite on my machine. the abstraction based patch measures 6ms and the one, that generates everything from scratch, measures ~300ms.
now, after claude's explanation, i think, i know why this is the case. i don't have any pathes loaded at all in my preferences. i try to do everything with [declare]s inside the patches. thus pd hasn't to search a whole bunch of pathes, but only the ones that are really useful.
roman
Hi Roman, Ok, after clearing out all the path and startup info under the "file" menu, my load times for the abstraction based patch have decreased by an order of magnitude. But now I'm puzzled because my results are the reverse of yours: test-abs.pd takes around 250ms and test-sp.pd takes 6ms.
Are there any other preferences you alter to restrict the paths that are searched?
hm.. probably due to different versions of pd on different platforms? i am on linux using pd-vanilla 0.42.5.
i am not totally sure, but after the second opening of the patch, the harddisk isn't accessed anymore, so i guess, the patches and abstractions are in the cache anyway. this makes me think, that it is not harddrive related.
i also found, that your measuring method was bogus. the loadbang inside abstraction will be executed _before_ the loadbang of the parent patch. i changed the patch and the result of test_sp.pd is now 1100ms. i attached fixed versions of all patches and abstractions.
roman
--- On Tue, 5/12/09, Roman Haefeli reduzierer@yahoo.de wrote:
From: Roman Haefeli reduzierer@yahoo.de Subject: Re: [PD] Abstraction load time To: jancsika@yahoo.com Cc: pd-list@iem.at Date: Tuesday, May 12, 2009, 11:53 PM On Tue, 2009-05-12 at 14:31 -0700, Jonathan Wilkes wrote:
--- On Tue, 5/12/09, Roman Haefeli
reduzierer@yahoo.de wrote:
From: Roman Haefeli reduzierer@yahoo.de Subject: Re: [PD] Abstraction load time To: "Jonathan Wilkes"
Cc: pd-list@iem.at Date: Tuesday, May 12, 2009, 9:39 PM it behaves like the opposite on my machine. the
abstraction
based patch measures 6ms and the one, that generates
everything from
scratch, measures ~300ms.
now, after claude's explanation, i think, i
know why
this is the case. i don't have any pathes loaded at all in my
preferences.
i try to do everything with [declare]s inside the patches.
thus pd
hasn't to search a whole bunch of pathes, but only the ones that
are really
useful.
roman
Hi Roman, Ok, after clearing out all the path and startup
info under the "file" menu, my load times for the abstraction based patch have decreased by an order of magnitude. But now I'm puzzled because my results are the reverse of yours: test-abs.pd takes around 250ms and test-sp.pd takes 6ms.
Are there any other preferences you alter torestrict the paths that are searched?
hm.. probably due to different versions of pd on different platforms? i am on linux using pd-vanilla 0.42.5.
I'm on winxp with 0.42.5.
i am not totally sure, but after the second opening of the patch, the harddisk isn't accessed anymore, so i guess, the patches and abstractions are in the cache anyway. this makes me think, that it is not harddrive related.
i also found, that your measuring method was bogus. the loadbang inside abstraction will be executed _before_ the loadbang of the parent patch. i changed the patch and the result of test_sp.pd is now 1100ms. i attached fixed versions of all patches and abstractions.
Oh man, I screwed up big time! Not only was the measuring wrong, but I mistakenly set test-sp.pd to create 1000 object chains instead of 100 -- that's why you're seeing such a large loading time for it. Very sorry about that. Here's a (hopefully) error-free version of everything.
I'll see if I can try these patches out on another machine to see if its my hardware, operating system, or both that's causing some of the slowness I get when loading the abstractions.
Thanks for the help, Jonathan
roman
-
Claude Heiland-Allen -
Jonathan Wilkes -
M. Edward (Ed) Borasky -
Roman Haefeli