[PD] Pd Development "Reverse Kickstarter"
jancsika at yahoo.com
Mon May 20 20:07:05 CEST 2013
On 05/15/2013 03:15 PM, Ivica Ico Bukvic wrote:
> On 05/14/2013 02:49 PM, Miller Puckette wrote:
>> Interesting idea. I agree that a non-lazy dev could just make argument
>> strings serve the same function (and sometimes it's good to see all the
>> args up front to prevent unnecessary allocations or computation).
>> Here's a thing to think about - how could abstractions (as opposed to
>> catch and use mesages separated by commas? There are lots of things
>> abstractions can't do cleanly (like have variable numbers of
>> and perhaps it could be helpful to use after-creation messages
>> somehow for
>> this. (I've always been nervous about the widespread use of
>> patches to fill this need :)
That is, whatever mechanism is used to parse the arguments to an object
box would be the same used by the "args" method of [canvasinfo]. So
you'd get an initial list of args to the outlet followed by a subsequent
message to the outlet for each comma separated message. (I suppose
"rawargs" would be a desirable method to add as well.) I need to look
back at Gridflow, because matju already implemented comma separated
syntax. All I remember is that he had an object which would send the
comma separated messages to the leftmost [inlet] which I didn't like.
But I don't know how it worked in object boxes, so I'll have a look.
As for "after-creation" as a general issue-- I'm sorry but it requires
[initbang]. There's just no way around it. You can call it a different
name, or you can hide it in args of a revised [loadbang] or implement it
in whatever manner you want but that is the solution, it's been
implemented, and it works.
Moreover, we cannot assume that every "after-creation" job which needs
to happen inside abstraction can be triggered by a user-specified,
comma-separated message. Easy example: imagine an object that sprouts
an extra inlet depending on whether or not an argument was actually
provided (like [select]). You don't want to force the user to type
[someobject, I don't have any args].
I'm sure there are other examples that don't even have to do with
arguments at all-- IOhannes has written about them somewhere on the
list. The point is that you cannot restrict "after-creation"
message-passing functionality to the domain of comma-separated
arguments. You simply need a _general_ way to output a bang after all
the objects inside the abstraction have been created. Though
comma-separated messages to abstractions depend on that, they are
themselves a separate issue.
> This may be a totally stupid idea but here it goes anyhow... What
> about creating a special nlet object that can dynamically change the
> number of nlets (in or out depending on a flag given) and issue
> command to gop object to redraw itself upon update? Doesn't seem to
> hard to implement but it does seem a bit unconventional, if you like...
Well to be honest if you don't want to dynamically instantiate objects,
then what other way is there aside from this approach?
More information about the Pd-list