[PD] Fwd: Variable number of objects?

Jonathan Wilkes jancsika at yahoo.com
Thu Sep 29 19:17:18 CEST 2011


What happens if you just have the maximum number of voices you think you'd ever need and 

[switch~] them on and off as needed?

Since you have a large patch, I'd be curious to know how much memory is taken up by 

having the switched off voices just sitting there.

-Jonathan



----- Original Message -----
> From: Ingo <ingo at miamiwave.com>
> To: 'Roman Haefeli' <reduzent at gmail.com>; 'Ludwig Maes' <ludwig.maes at gmail.com>
> Cc: 'Pd List' <pd-list at iem.at>
> Sent: Thursday, September 29, 2011 5:33 AM
> Subject: Re: [PD] Fwd:  Variable number of objects?
> 
> Actually, I just tried again to simply copy a couple of voices and it only
> took a fraction of a second with a very short dropout - even with the dsp
> on.
> 
> I have recently installed Natty instead of Lucid on a new machine. Maybe it
> has something to do with realloc that Mathieu mentioned.
> 
> So it looks like dynamic patching of voices isn't "that" much of a 
> problem
> here anymore. It still takes 7-8 seconds to create 16 voices in my case with
> the dsp off (12 with the dsp on) but that's still faster than restarting the
> patch. I would never have checked again if nobody would have mentioned it.
> 
> I have attached a patch that I used for testing. These voices were receiving
> their input with [receive] so no connections were needed. If you are using
> wired inlets you will have to dynamically add the connections of course.
> 
> I added a cut & paste at the end because for some reasons the voices 
> didn't
> get initialized correctly. Not sure if this is needed for other
> voice-abstractions.
> 
> Ingo
> 
> 
>>  -----Ursprüngliche Nachricht-----
>>  Von: pd-list-bounces at iem.at [mailto:pd-list-bounces at iem.at] Im Auftrag von
>>  Roman Haefeli
>>  Gesendet: Donnerstag, 29. September 2011 08:36
>>  An: Ludwig Maes
>>  Cc: Pd List
>>  Betreff: Re: [PD] Fwd: Variable number of objects?
>> 
>>  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
>> 
>> 
>> 
>>  _______________________________________________
>>  Pd-list at iem.at mailing list
>>  UNSUBSCRIBE and account-management ->
>>  http://lists.puredata.info/listinfo/pd-list
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



More information about the Pd-list mailing list