[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