[PD] abstraction setting its own arguments

Mathieu Bouchard matju at artengine.ca
Mon Aug 2 18:09:31 CEST 2010


On Mon, 2 Aug 2010, Jonathan Wilkes wrote:

>> « error: [args hello (world a 42) *] inlet 0 method
>> loadbang: can't send init-messages, because object has no
>> [inlet] »
>
> No, it just crashes.

I suppose you can also find other situations in which GF crashes instead 
of reporting an error message ?

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

It's confusing while you don't expect it. Once it's expected, it's not any 
more confusing than receive-symbols hidden inside IEMGUI properties 
dialogues.

> Why did you choose to do that?

Because [args] used to have a right outlet to be connected to the top left 
[inlet] and it would always go across the whole patch in some ugly way. I 
could have made it left outlet instead, but figured out that if I could 
save a bit of boilerplate (usually a [t a] and two more wires) in every 
abstraction, I'd have that much less in every abstraction, and I wouldn't 
have to verify all abstractions to make sure that they support the 
init-commas.

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

That's not the only well-ordered one : you can do clear-looking partial 
ordering of loadbangs by using subpatches (with nesting or not). All 
subpatch [loadbang]s are guaranteed to be finished before their immediate 
parent's [loadbang]s.

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

I may as well do search-and-replace on all of GridFlow. I shouldn't care 
so much about backwards-compatibility when not only other people don't 
contribute abstractions to GF, but also, there's no one even saying 
something like « I use [args] ». Then why bother.

But at this point, my idea of it is to make it a comma-option in [args] :

   [args foo bar *, noloadbang]

and then think some more before getting into anything not 
backwards-compatible.

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

bang is not a single-element message : it has no $1.

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

What does that case exclude ?... only "loadbang" and "dsp" ? (but then, 
not even necessarily).

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

this is why method <any> appears last, for a given inlet or outlet.

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

No. The one I mean here is more like : if you put $@ alone in a message 
box, you'll get "an anything" in the sense that the possible values of $@ 
make most any message possible. This includes the case where the value of 
$1 is "list", in which case the $1 of the output will be the $2 of the 
input. (In effect, this would be a shortcut of [list trim].)

Whereas you get "a list" if you write "list $@" in it because you can only 
make list-messages that way.

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

Didn't really think about it. Any ideas ?

I suppose that there would be a point soon when I will have a better idea 
about what to do, but I only _started_ using [setargs] very recently, so, 
I don't know yet.

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


More information about the Pd-list mailing list