[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.


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