[PD] Best practice for abstractions with many parameters

[Phil Stone]

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