Just curious, but has anyone tried to test the performance differences between sending messages as compared to actually connecting things up with wires?
I am curious weather or not one of my patches would work with messages, as I want to instantiate close to 200 oscillators, with each taking about 7 or 8 parameters per grain. Mike On 4/25/08, Roman Haefeli <[EMAIL PROTECTED]> wrote: > On Fri, 2008-04-25 at 20:09 +0200, Frank Barknecht wrote: > > Hallo, > > Mike McGonagle hat gesagt: // Mike McGonagle wrote: > > > > > And yes, while this is possible, it just seems very "difficult" at best, > to > > > be able to create a patch and lay it out in such a way that you can make > > > those sorts of selections. LOTS of planning would need to go into such a > > > thing. > > > > What I generally do *if* I'm doing dynamic patching is write as much as > > possible into an abstraction and just create copies of that. nqpoly4~ > > may help with automating that. > > > > A very useful trick for these abstractions is to avoid doing connections > > at all and just pass $0 as an argument. Then inside the abstraction, use > > [r $1-inlet] receivers where $1 is the $0 of the parent as passed as > > argument instead of inlets, and [s $1-outlet] instead of outlets. Outside > of > > the patch use [s $0-inlet] to write to the fake inlet, and [r $0-outlet] > > to read from the fake sender outlet. Do the same for signals with r~/s~ > > and throw~/catch~ pairs. Most dynamic connections can be avoided by this > > approach. > > > > If you need to pass data from one dynamically created abstraction to > > another, use a similar approach with numbered arguments. Again this can > > be seen in action in the redesign of nqpoly4~.pd that I once did and > > that's in svn/pd-extended as well, or in polypoly.pd. > > > > this is basically the approach, that probably all dynamic patches from > netpd are based on. no connections are created or deleted dynamically > (it's just too cumbersome and relies on undocumented features). > parts that need to be deleted separately go into their own subpatch, so > that they can be deleted simply by sending 'clear' to the appropriate > subpatch. > > however, there _are_ issues, that cannot solved that way. whenever > signals are involved with dynamically created abstractions, it's likely > to get one-block-delays due to the creation order of the > [throw~]s/[catch~]es and [send~]s/[receive~]s. don't know how to deal > with that yet. > > > roman > > > > > ___________________________________________________________ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
