[PD] Fwd: Variable number of objects?

[Ingo]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: create_voices.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110929/e8bd4d81/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: samplevoice.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110929/e8bd4d81/attachment.asc>