[PD] Best practice for abstractions with many parameters

[Phil Stone]

Hi Jamie,

Nice to hear from you.  I've been having fun with a_grain, and I'm 
beginning to understand it a little better.

I've attached what I've done with it so far, which uses the 
no-wire/message method I described below.  I don't think this is always 
the best way to go about this (see discussion on this thread), but I'm 
finding it useful in this case, because it makes a complex patch with 
many inputs easier to read.  Also included is the test runner (derived 
from yours), which shows how the message sending objects (number boxes 
and toggles) send to prefix-tagged destinations in the a_grain 
abstraction (the prefix being passed to a_grain as its third argument).

I've only begun to "untangle" a_grain, as you can see.  But at least I 
can see what the various parts are doing at this point.  Very cool.  
I've only included the two files I changed, by the way.  Anyone else 
wanting to actually try these changes needs to get the original folder from

http://www.puredata.org/Members/jb/a_grain%7E/view 

then copy a_grain~.pd over its namesake, and add a_grainTest.pd to the 
folder and run it.

I'm enjoying a_grain and it's helping me understand granular synthesis à 
la PD; thank you for making it and putting it out there.


Phil Stone
UC Davis


Jamie Bullock wrote:
> 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
>>     
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a_grainTest.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061013/f59bc74d/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a_grain~.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061013/f59bc74d/attachment.txt>