My first thought is that I think that inlets are a more intuitive way
of handling input parameters in Pd. But there is definitely a limit
to how many inlets and outlets you can have. I try to break down the
problem into small enough units so that only inlets can be used, no
parameter messages.
If you have more than 5 or so parameters, then I think a message-
based parameter system is necessary. Then I think that it should be
only a message-based system, not something like 5 inlets which one
inlet that handles a bunch of extra messages. Keep in mind, these
are general rules, so I am sure there occasional exceptions where it
makes sense.
It the case that you describe, I would first try to break up the
problem into more objects, maybe one that handles enveloping/
windowing and one that handles grain making (I am just guessing here,
I don't know a_grain). But if you still want it to be one object
with 14 paramenters, I would make everything use messages, like you
suggest.
.hc
On Oct 12, 2006, at 2:24 PM, Phil Stone 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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson