[PD] Fwd: Variable number of objects?

Roman Haefeli reduzent at gmail.com
Thu Sep 29 08:35:45 CEST 2011


On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
> 
> 
> ---------- Forwarded message ----------
> From: Ludwig Maes <ludwig.maes at gmail.com>
> Date: 28 September 2011 19:29
> Subject: Re: [PD] Variable number of objects?
> To: Ingo <ingo at miamiwave.com>
> 
> 
> I actually meant more in general, also for non-~ signals (i.e. also
> control rate .pd patches). I referred to polysynth such that people
> would see more easily what I meant. Are there really no such
> primitives? That seems like quite a restriction...
> 
> How can that take 10 seconds?? I dont see what would cause such a huge
> overhead, i'd expect an increase in computations & memory though (say
> from 10 voices to 11: 10% increase in cpu workload & ram dedicated to
> these voices..., I fail to see what would necessitate a long
> initialization...)
> 
> also, how is it done even with the long delays?
> 


As I understand it, the whole DSP is recompiled whenever it is changed.
So, if you have a very large patch (and Ingo seems to be an expert in
very large patches) and you create another voice, it's easily possible
to eat up quite some time. 

Also, it's probably much slower the first time, if the voice abstraction
is built of many other abstractions, which need to be read from disk. 

But I guess you are right about the increase in CPU workload _after_ the
DSP graph has been recompiled: A switch from 10 two 11 instances is
expected to show only an increase of 10% in CPU usage.  

It's been said, that often you can gain quite some time while turning
off DSP during dynamic instantiation. But I guess, this makes only a
difference when performing several instantiations at the same time. When
DSP is on, each cycle would cause a complete DSP graph recompilation,
whereas when DSP is off, it's only recompiled once (after turning it on
again).  



Roman





More information about the Pd-list mailing list