--- On Sat, 8/7/10, Mathieu Bouchard <ma...@artengine.ca> wrote:
> From: Mathieu Bouchard <ma...@artengine.ca>
> Subject: Re: [PD] abstraction setting its own arguments
> To: "Jonathan Wilkes" <jancs...@yahoo.com>
> Cc: pd-list@iem.at
> Date: Saturday, August 7, 2010, 2:06 AM
> On Mon, 2 Aug 2010, Jonathan Wilkes
> wrote:
> > --- On Mon, 8/2/10, Mathieu Bouchard <ma...@artengine.ca>
> wrote:
> >> 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.
>
> That's quite a problem, because I can't think of anything
> that would make this error message any more crash-prone than
> the standard error messages you get in GF externals (GF
> abstractions are a different matter though, because then,
> many error messages would come from Pd instead).
>
> >> 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.
>
> My comparison with IEMGUI is to mean that once you start
> with the supposition that every message travels along a
> wire, you hit one exception with [r]/[s] and it's fine, then
> you hit another exception with hidden implicit [r]/[s]
> inside IEMGUI and floatatom/symbolatom and it's fine as
> well, and then you hit another exception with [args] and I
> don't know why it would be less fine.
Well for one thing, in all those cases you can control where the
messages end up (or which messages arrive) using send/receive names.
With [args] the blueberries appear in my cereal bowl without me having
gone to the refridgerator to retrieve them. And if I want to pour
[milk~] instead of [milk] the refridgerator quits running.
>
> > What if the abstraction in question doesn't have any
> xlets, but the user wants to use key/value pairs?
>
> If an object has no need for an inlet, then it doesn't
> matter whether there is one at all.
>
> And then, the point of key/value pairs in left inlets is to
> ensure that every attribute is settable at runtime in the
> same manner as it is settable in the objectbox. It is
> enforcing a standard by making it convenient to follow the
> standard. Thus, the perspective of [args] on key/values is
> that objects that use them should have an [inlet] so that
> those attributes can be reconfigured at any time if the user
> wants it.
>
> I could add an option to make it differently (actually,
> backward-compatible with the older [args] that didn't do
> that yet) but I don't really see a purpose for which I'd say
> « yes, it's a good idea to make this attribute
> non-reconfigurable ».
>
> > 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.
>
> You know, if it's a GOP, then the [inlet] can be hidden by
> putting any GOP-visible component on top of it. the GFDP
> components such as [doc_i] and [doc_m] are covering the
> inlet-space, at least in run-mode (those two particular
> classes only do so in run-mode).
>
> I'm actually also toying with the idea of adding inlets to
> [doc_m] and such, during the « GFDP rewrite », that is,
> some major change to GFDP that I expect would be the last
> big change. I don't know when that rewrite would happen.
> I'll try to make it as gradual as possible (simply because
> big changes are much harder to finish than the sum of their
> parts...)
>
> > It might be something relevant to the GFDP, so I'll
> send it to you after I flesh it out.
>
> ok
>
> >>> 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).
>
> [loadbang] does not send to any objects that only have a
> anything-method. It only talks to objects that explicitly
> define "loadbang". Same for "dsp".
>
> (In both cases, this is an exception in the sending, not
> the receiving, ... but that distinction doesn't even matter
> to a writer of externals, in which case all that matters is
> that class_addanything is not enough)
>
> > How is your definition different than my 2nd one
> above?
>
> Oops... either there was no difference at all, or there was
> something very subtle and I forgot what it was.
Well, I'd like to figure out the simplest way to write this particular
definition so that someone unfamiliar with this e.e. cummings-like
language has a chance of understanding it.
>
> > 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.
>
> Right. That sounds like something to consider, for the
> future...
>
> But also, another big difference is that it does a job of
> [unpack]ing, that the messagebox doesn't do. Therefore, in
> that case, to follow an analogy with the messagebox, it's
> ambiguous whether there ought to be a complementary implicit
> [pack] behaviour in [args], causing it to have as many
> inlets as it has outlets.
If you did that then are all the inlets "hot"? Or would a "bang" to
the left inlet both update and output the args?
>
> _ _ __ ___ _____ ________ _____________
> _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone:
> +1.514.383.3801
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
