[PD] abstraction setting its own arguments

[Jonathan Wilkes]

--- On Sun, 8/1/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: Sunday, August 1, 2010, 7:40 PM
> On Sat, 31 Jul 2010, Jonathan Wilkes
> wrote:
> 
> > * the magical [inlet] message on loadbang is weird and
> will cause a
> > crash in winxp if you happen to remove the
> abstraction's inlet.
> 
> You mean you don't get the following error message ?
> 
> « error: [args hello (world a 42) *] inlet 0 method
> loadbang:
>   can't send init-messages, because object has no
> [inlet] »
> 
> > * sending output from [args] on loadbang is redundant
> when
> > [loadbang]-[args] is so trivial.

No, it just crashes.  But my bigger point is that it's really confusing 
behavior for messages to be coming out an inlet at loadbang time when 
nothing is actually connected to that inlet.  Why did you choose to do 
that?

> 
> lots of shortcuts are trivial individually, then pile up to
> make a difference.
> 
> The problem with auto-[loadbang] in args is that [loadbang]
> order is a dangerous thing (which I forgot to think about
> when designing that part of [args]... not sure what to do
> with it now... a bit hard to undo).

Exactly. The clean patching solution for multiple loadbangs is pretty 
easy: [loadbang]-[t b b b etc.] . (I actually used that even before 
thinking about the problem of [loadbang] order because it just seemed 
like a simple, readable way to do it.)

Maybe you could have another object with a different name like [getargs] 
that doesn't do the loadbang.

> 
> > Is there anything [args] can currently do that
> wouldn't be possible by taking an "anything" at its inlet?
> 
> What would be the meaning of that "anything" ?

I don't know why I said "anything" and not "list". I guess I was 
thinking that $@ expands to an anything and not a list (unless the 
first arg is a float).  But as you show, it would most likely arrive at 
[args] as a list anyway...

> 
> you mean plugging [loadbang]-[list append $@] into it ?...
> maybe it would work, but it would be two more objects per
> abstraction, too. (and it wouldn't be a "anything". why
> "anything" ?)

Yes, in this case I would say "list".

But since I'm working on clarifying the docs...

The word "anything" seems sometimes to be used in opposition to the 
list message, to refer to a multi-element message with a selector 
other than "list" (or a single-element message with selector other 
than bang, symbol, float, or pointer).

At other times it seems to mean any message that would be accepted by 
the anything-method, which includes list messages as well as the other 
pd built-ins. (like [any], [send], [spigot], etc. )

And at further other times, it seems like it means "other than x/y/z, 
anything", as in, "other than 11 reserved selectors, you can send anything 
to [bng] and it will trigger a bang."

Do any of these fit your definition of "anything"?

> 
> > 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).
> 
> I expect to add this feature whenever someone needs it :
> 
>   [args *, nocommas]
> 
> would consider commas as non-special. Also :
> 
>   [args *, nocommas, noparens]
> 
> would completely disable special parsing. But it's also
> possible that the syntax would be :
> 
>   [args *, commas 0, parens 0]
> 
> a 0/1 attribute specified without a value defaults to 1. I
> haven't really thought about a rule for what is better,
> negative bools (names with "no" in them) when they sound
> good (mainly for exceptional cases), or positive bools all
> over.
> 
> > 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
> 
> You know, passing [loadbang]-[list append $@]-[args] isn't
> making [args]'s code any shorter than with an autonomous
> [args] as it is now.
> 
> And then, for the handling of abstractions' properties
> dialogues, I'm going to do something rather close to a
> list-method for [args], without doing it : I'm going to use
> [setargs] just before re-banging the [args]. It's the only
> way I can think of using [args] with an input that is not
> just the original arguments of the abstraction-instance...

Why are [args] and [setargs] two separate objects?

> 
> > without burdening the users with learning a completely
> different way of getting args every time they want to do
> something different with them.
> 
> I'm all for adding $@ to pd-extended, but by itself, its
> inclusion in pd-extended doesn't seem like a reason to
> change anything in [args] at all. In any case, if you feel
> like $@ has to be included in pd-extended, that's something
> you have to talk to Hans about.
> 
>  _ _ __ ___ _____ ________ _____________
> _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone:
> +1.514.383.3801