[PD] Best practice for abstractions with many parameters

[Hans-Christoph Steiner]

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 at 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