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
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@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list