[PD] Best practice for abstractions with many parameters

[Kyle Klipowicz]

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

On 10/12/06, Phil Stone <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 mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 

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

(((())))(()()((((((((()())))()(((((((())()()())())))
(())))))(()))))))))))))(((((((((((()()))))))))((())))
))(((((((((((())))())))))))))))))))__________
_____())))))(((((((((((((()))))))))))_______
((((((())))))))))))((((((((000)))oOOOOOO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061012/0cfb4566/attachment.htm>