[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