[PD] Array indexing for the wind and the birds

[Roman Haefeli]

On Fri, 2007-10-26 at 10:13 +0200, Enrique Erne wrote:
> 
> On Ven Oct 26  1:26 , Roman Haefeli  sent:
> 
> >On Thu, 2007-10-25 at 16:22 -0400, Mathieu Bouchard wrote:
> >
> >> On Tue, 23 Oct 2007, Roman Haefeli wrote:
> >
> >> 
> >
> >> > the main problem with dynamic patching is, that it is very likely, that 
> >
> >> > it causes audio drop-outs.
> >
> >> 
> >
> >> It wouldn't take much code to introduce something that can wrap dynamic 
> >
> >> patching in a way that prevents any DSP recompilation at the wrong moment.
> >
> >> 
> >
> >> E.g. If I have a patch that has 40 DSP objects, and then I instantiate an 
> >
> >> abstraction that has 10 dsp objects, 20 times, this recompiles DSP 20 
> >
> >> times, taking a total of 10*(40+(10+10*20)/2) = 1450 dsp_add calls. If the 
> >
> >> dynamic creations dominate, the time increases quadratically, which is one 
> >
> >> kind of "gets bad quite quickly".
> >
> >> 
> >
> >> Bracketing a bunch of dynamic object creations with a dsp-disable / 
> >
> >> dsp-enable pair, you just recompile once at the end, in the above example 
> >
> >> totalling to 40+10*20 = 240 dsp_add calls, which is exactly the size of 
> >
> >> the dsp graph you have at the end.
> >
> >
> >
> >that is what i do in netpd since last change. whenever a patch is
> >
> >loaded, it is not openen per message anymore but created dynamically as
> >
> >an abstraction. i found out, that it takes _much_ less time, if dsp is
> >
> >turned off before and turned on after creating it. this is probably the
> >
> >difference between what you describe as linear and quadratic increase. 
> >
> >
> >
> >> Getting any better than linear time is somewhat harder, especially for pd, 
> >
> >> but linear is already much better than quadratic.
> >
> >> 
> >
> >> > especially when creating ~-objects, the dsp graph needs to be 
> >
> >> > recompiled, which requires some cpu power.
> >
> >> 
> >
> >> ... uninterruptible cpu power.
> >
> >> 
> >
> >> but if patches don't expect the dsp to be updated immediately, the job 
> >
> >> could be spread over several logical time blocks.
> >
> >
> >
> >don't know how to do that. there is no way in pd to tell how much behind
> >
> >schedule pd is with computing, or is there? anyway, in the case of netpd
> >
> >it wouldn't help anyway, since complete patches are created as single
> >
> >abstractions. i wouldn't know how to break that into smaller chunks.
> >
> 
> there was a thread: slowly load patches/abs without dropout
> 
> http://lists.puredata.info/pipermail/pd-list/2007-01/046107.html
> 
> the attached patch reads and creates a patch slowly triggered by a metro. as far
> as i remember i didn't implemented a correct array-creation.
> 
> eni

didn't that thread end with the conclusion, that

a) it is very hard to do that in pd, since message to canvasses are
different from the lines in the pd-file? 

b) this is something that should rather managed by pd itself and not in
userspace?

and still, if you do it in userspace,  there is no way to tell
beforehand, how many objects you can create in a certain amount of time
without getting dropouts. that means, if you really want to avoid
drop-outs, you would have to do it very slowly, probably so slowly, that
it takes ages to recreate a whole netpd patch.  if there'd be a way to
create constantly as many objects so that pd is just on the edge of
having a dropout, but doesn't, then it would _might_ be worth to do it
in userspace.

roman



roman



	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de