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