[PD] abstraction setting its own arguments
jancsika at yahoo.com
Sun Aug 1 01:59:50 CEST 2010
--- 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
> > 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.
> _ _ __ ___ _____ ________ _____________
> _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone:
More information about the Pd-list