[PD] Pd Development "Reverse Kickstarter"

[Jonathan Wilkes]

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 
>> externs)
>> catch and use mesages separated by commas?  There are lots of things
>> abstractions can't do cleanly (like have variable numbers of 
>> inlets/outlets)
>> and perhaps it could be helpful to use after-creation messages 
>> somehow for
>> this.  (I've always been nervous about the widespread use of 
>> self-modifying
>> patches to fill this need :)

[args(
|
[canvasinfo]
|

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.

-Jonathan

>>
>> cheers
>> Miller
>>
>
> 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?