Beware of NOT wiring enough. 

Of course, we've all seen what beautifully unintelligible spiderweb artwork people are capable of spewing out when they don't patch with the courtesy of showing their ideas methodically.  But an invisible web of sends and recieves can be just as misleading. 

I like to use a combination, where there is a single [inlet] to a [route] that uses local [send]/[recieve] pairs within the abstraction.  I really like this idea of Frank's to use one "master" send/recieve pair and then weed it all out with [route] objects:  it makes it easier to remember what to type!

~Kyle

On 10/12/06, Phil Stone <pkstone@ucdavis.edu> wrote:

Pardon me for replying in this clumsy way, but I'm not sure how to
maintain thread integrity on my replies, since I receive PD-list in
digest mode.  Since Kyle was kind enough to write me directly, I'm
hoping replying to him and his cc of the list will preserve the thread.
In reality, though, I'm replying to a few people at once here.


Kyle Klipowicz wrote:
> I can already anticipate what some might suggest:  try using a single
> inlet and then pipe that to [route] or [OSCroute].
>
> Then you can use descriptive messaging to both a) provide better
> information about what data is going where, and b) cut down on having
> a zillion inlets at the top of your abstractions.
>
> Using OSC style messaging is handy too--just look at RRadical for an
> example.
>
> ~Kyle

This does seem like a good idea, and Frank's follow-up is intriguing,
too.  My only objection to it is that you still have a lot of wiring
that you wouldn't have with my second approach, i.e., you still have to
patch the output of [route] or [OSCroute] to the various places the data
is needed.  Plus, you need to pack the sent information in one place on
the parent patch -- another jumble of wires or an additional set of
send-receives.   I think symbolic routing is a good idea in general,
though, so maybe these are not such important considerations.


carmen writes:
> >Now it occurs to me that I could eliminate the inlets entirely, and just write to send/receive pairs >directly
>
>
> how do you find out which instance to send to. are you accessing the abstraction's $0 from outside the abstraction

One idea, which I've used successfully on another patch, is to add a
parameter to the abstraction which is a message prefix.

So, if I called [a_grain~ env samp xyz]  the third argument 'xyz' would
be the message prefix (it could be anything one liked, even '$0' if you
only needed to distinguish one set of messages for an abstraction).
Senders in the parent patch would send to xyz-(whatever), as in [s
xyz-pointerhop].

The abstraction has [receive] objects of the form  [r $3-pointerhop].
Each instantiation of that abstraction will therefore only receive
messages intended for it, and one can address as many copies as one likes.

What I like about this is the lack of wires.  In the parent patch,
there's no wiring (!).  I just assign appropriate sends, with the
correct prefix, to my sliders, number boxes, etc.  In the
abstraction(s), there's an appropriately named (with the $3 prefix)
receive object sitting right next to whatever needs the message.

I do want to go to the next stage and learn how to persist presets, so
Frank's tutorial is particularly appreciated.  I'll probably adopt his
system for its obvious advantages.  I'm just trying to train myself to
"think PD" in the most efficient way, in the meantime.

Thanks for the responses,


Phil Stone
UC Davis

>
> On 10/12/06, *Phil Stone* < pkstone@ucdavis.edu
> <mailto:pkstone@ucdavis.edu>> wrote:
>
>     I've been playing with Jamie Bullock's 'a_grain' lately (see
>     http://www.puredata.org/Members/jb/a_grain%7E/view ), and in order to
>     understand it better, I've been refactoring it.
>
>     A_grain has 14 inputs to control various parameters; my first
>     approach
>     to cleaning it up was to put all the inlets, in the correct order, at
>     the top of the patch -- I then connected those inlets to 'send'
>     objects
>     with $0 variables, placing matching 'receive's close by where they
>     are
>     needed.  This really cleaned up the wiring quite a bit, and made it
>     easier to "read".
>
>     Now it occurs to me that I could eliminate the inlets entirely,
>     and just
>     write to send/receive pairs directly (perhaps also passing in a
>     "prefix"
>     as an argument that is prepended to all receives inside the
>     abstraction,
>     which would allow multiple instantiations of the abstraction, with
>     independent control of each).  At the UI-level patch, I could use
>     named
>     senders (from number boxes, sliders, whatever) just hovering
>     nearby the
>     a_grain abstraction; no wires, no mess.
>
>     I'm wondering what experienced PD architects consider the best
>     practice
>     here; if the second approach is better, I begin to question the
>     advisability of wired inlets for more than two or three
>     arguments.  The
>     left-to-right ordering of them, along with the rats-nest wiring caused
>     by high numbers of inputs, seem to argue against them.  The only
>     downside I can see to the second method is that if it's not done
>     neatly,
>     i.e., the senders are placed indiscriminately and not necessarily near
>     the abstraction they're sending to -- it could become very hard to
>     understand/maintain the patch.
>
>     I'll be interested to hear other PD user's thoughts on this.
>
>
>     Phil Stone
>     UC Davis
>
>     _______________________________________________
>     PD-list@iem.at <mailto:PD-list@iem.at> mailing list
>     UNSUBSCRIBE and account-management ->
>     http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> --
>
> http://theradioproject.com
> http://perhapsidid.blogspot.com
>
> (((())))(()()((((((((()())))()(((((((())()()())())))
> (())))))(()))))))))))))(((((((((((()()))))))))((())))
> ))(((((((((((())))())))))))))))))))__________
> _____())))))(((((((((((((()))))))))))_______
> ((((((())))))))))))((((((((000)))oOOOOOO

--

http://theradioproject.com
http://perhapsidid.blogspot.com

(((())))(()()((((((((()())))()(((((((())()()())())))
(())))))(()))))))))))))(((((((((((()()))))))))((())))
))(((((((((((())))())))))))))))))))__________
_____())))))(((((((((((((()))))))))))_______
((((((())))))))))))((((((((000)))oOOOOOO

_______________________________________________

PD-list@iem.at mailing list

UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list