[PD] pd-msg

[Mike McGonagle]

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