I second that thought! I have recently begun to try to avoid send/
receive as much as possible and instead focus on encapsulation in
abstractions and subpatches. I think this makes for much cleaner,
more readable, and less buggy code.
.hc
On Oct 12, 2006, at 6:03 PM, Kyle Klipowicz wrote:
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 inorder 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 correctorder, at
the top of the patch -- I then connected those inlets to 'send' objects with $0 variables, placing matching 'receive's close by wherethey
are needed. This really cleaned up the wiring quite a bit, andmade 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 coulduse
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-nestwiring 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 notnecessarily near
the abstraction they're sending to -- it could become veryhard 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
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore