[PD] pd-msg
Mike McGonagle
mjmogo at gmail.com
Sat Apr 26 00:06:32 CEST 2008
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 <reduzierer at yahoo.de> 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
>
>
>
> _______________________________________________
> PD-list at iem.at 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
More information about the Pd-list
mailing list