On Wed, 9 Sep 2009, Phil Stone wrote:
Thanks for clarifying that, Hans, and for pointing out the issue with
threads, IOhannes. One shouldn't be profligate with [pd~]s, strewing
them all about and expecting performance gains -- therefore, one [pd~]
per voice instance in a [polypoly] patch is
Phil Stone wrote:
Hi Hans,
Thanks for replying. I don't quite understand what you mean by
manually manage. As far as I know, without something like [pd~],
there's no way to divide up and assign the Pd audio process to more than
one core. Half of the cores on a quad-core are therefore
Sorry if this question is obvious, may be an alternate for live audio
processing with clusters:
does it exist some netsend/netreceive for audio in Puredata ?
I remember having using one (experimental) few years ago but was within
MaxMSP...
fred
IOhannes m zmoelnig wrote:
Phil Stone wrote:
Networking has a lot of latency and jitter, so not so good for
realtime audio. As for manually managing pd~, I mean just manually
creating as many pd~ instances as you have cores.
.hc
On Sep 9, 2009, at 5:06 AM, fred-ordi wrote:
Sorry if this question is obvious, may be an alternate for
Thanks for clarifying that, Hans, and for pointing out the issue with
threads, IOhannes. One shouldn't be profligate with [pd~]s, strewing
them all about and expecting performance gains -- therefore, one [pd~]
per voice instance in a [polypoly] patch is probably not a good idea
until we have
Hello all,
I have skimmed Miller's paper from Pd-con about [pd~], and it looks like
it has potential for taking advantage of multiple-core CPUs. I need to
read it in a little more detail to digest it fully, but I'm wondering
(and this is directed mostly at Frank B.): could [polypoly] and/or
Hi Hans,
Thanks for replying. I don't quite understand what you mean by
manually manage. As far as I know, without something like [pd~],
there's no way to divide up and assign the Pd audio process to more than
one core. Half of the cores on a quad-core are therefore useless to Pd
