[PD] abstraction setting its own arguments

[Jonathan Wilkes]

--- On Sat, 7/31/10, Mathieu Bouchard <matju at artengine.ca> wrote:

> From: Mathieu Bouchard <matju at artengine.ca>
> Subject: Re: [PD] abstraction setting its own arguments
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: pd-list at iem.at
> Date: Saturday, July 31, 2010, 9:12 PM
> On Sat, 31 Jul 2010, Jonathan Wilkes
> wrote:
> 
> > That's just an example.  But I think it is the
> best way to handle getting args inside an abstraction
> because it obviates the need for all of the "arg-getting"
> objects scattered about pd-extended,
> 
> It still wouldn't support non-default defaults of [args],
> nor support the ()-parsing that [args] does,
> nor handle the
> comma-message feature of [args]. I think that you are making
> overly broad assumptions about people's needs.

I'll definitely have to play around with [args].  Some things I see 
up front are:
* the magical [inlet] message on loadbang is weird and will cause a 
crash in winxp if you happen to remove the abstraction's inlet.
* sending output from [args] on loadbang is redundant when 
[loadbang]-[args] is so trivial.

Ok, I certainly don't have the know-how to refactor $@ for inclusion 
in Pd-extended, but here's my thought: it's more flexible to have one 
standard "arg-getter" like $@ and one or more "arg parsers" than it 
is to have one or more "arg swiss army knives".

Is there anything 
[args] can currently do that wouldn't be possible by taking an 
"anything" at its inlet?
Because currently, with [args]-- but without 
$@ in pd-ext-- I cannot create an object in an abstraction that has 
a variable number of args without relying on dynamic patching.  In 
my experience this involved [expr] but there are probably other 
examples where this technique would come in handy.  Additionally, your 
method of using commas to separate named init values assumes 
that the pd programmer doesn't want to send commas as arguments (which 
I did want to do in my [expr] example).  So what I'm saying is that 
your [args] doesn't fit my needs, and $@ wouldn't fit everyone's 
needs, but $@ + [args] + [other_parsers_as_needed] would fit 
the maximum number of needs without burdening the users with learning a 
completely different way of getting args every time they want to do 
something different with them.

-Jonathan

> 
>  _ _ __ ___ _____ ________ _____________
> _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone:
> +1.514.383.3801