[PD] Best practice for abstractions with many parameters

[Hans-Christoph Steiner]

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 at 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 at ucdavis.edu
> > <mailto:pkstone at 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 at iem.at <mailto:PD-list at 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 at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061012/bc2c83ef/attachment.htm>