--- On Mon, 8/2/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Monday, August 2, 2010, 6:09 PM 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 ?
That's the only I've seen so far. I haven't used GF much yet.
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.
But IEMGUI receive-symbols don't make any assumptions about whether or not there is an inlet in a particular canvas. What if the abstraction in question doesn't have any xlets, but the user wants to use key/value pairs?
Actually there's a particular doc-related example I have in mind that would benefit from key/values in the args but doesn't have xlets. It might be something relevant to the GFDP, so I'll send it to you after I flesh it out.
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.
Right. Other messages consisting of only a selector are part of this definition, too.
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).
It includes those messages (well, maybe not "dsp" with signal objects-- that's special).
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.
Ok. I just explain it explicitly for those objects that require it.
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].)
How is your definition different than my 2nd one above?
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 ?
An [args] that does both setting and getting would be somewhat analogous to a "luxury" message box. You use all the same messages to set the content, and sending a bang would output the content. The big difference I guess is that with args you can tell it default values to output if there are no args, which you can't do with a message box.
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