[PD] Best practice for abstractions with many parameters

[Jamie Bullock]

On Thu, 2006-10-12 at 11:24 -0700, 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.
> 

Great news! 

> 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".
> 

Looking back at it I'm really glad I provided some documentation. The
patch is a complete mess!

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

The approach I am starting to use for all of my abstractions is to have
the first inlet, and first outlet for all control-rate data, and use
messages containing key/value tuples passed to [route] objects inside
the abstraction to pass data in. What I like about this that once
everything is connected up it is easy to see what parameters the data
coming into the abstraction correspond to. It is also possible to
implement a kind of pseudo-inheritance by nesting abstractions that
implement this approach. 

Anyhow, I look forward to seeing the results of your refactoring. I
think it will inspire me to add some more features to [a_grain~] as per
the TODO...

best,

Jamie


> 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