[PD] abstraction setting its own arguments
jancsika at yahoo.com
Mon Aug 2 22:37:27 CEST 2010
--- On Mon, 8/2/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: Monday, August 2, 2010, 6:09 PM
> On Mon, 2 Aug 2010, Jonathan Wilkes
> >> « error: [args hello (world a 42) *] inlet 0
> >> 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
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
> > 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
> > 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--
> > 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:
More information about the Pd-list