[PD-dev] abstractions

Mathieu Bouchard matju at artengine.ca
Tue Jul 8 19:55:07 CEST 2008


On Tue, 8 Jul 2008, mescalinum at gmail.com wrote:

> but has also an additional drawback: you have to add '$0-initbang bang;' 
> each time you edit the patch in pd, cause pd discards everything it 
> doesn't know about.

This can be solved easily by doing something like this:

t_class *c;
void at_init_new (t_symbol *, int argc, t_atom *argv) {
 	t_binbuf *b = binbuf_new();
 	binbuf_add(b,argc,argv);
 	binbuf_eval(b,0,0,0);
 	binbuf_free(b);
 	return pd_new(c); /* bogus, just so that it gets saved */
}
c = class_new(gensym("at_init"),at_init_new,0,sizeof(t_object),0,0);

That way, you have a version of the same thing that will be saved by the 
regular canvas-saving mechanism and will be otherwise the same. Thus this 
line:

   \$0-initbang bang;

Would look like this instead:

   #X obj 242 666 \$0-initbang bang;

But the problem with that one is that this object has to occur last in the 
list of objects, but anyway, as I said, the patch is already sensitive to 
its own object-numbering, so this kind of external doesn't really improve 
anything. (Your patch is also sensitive to connection-ordering, but this 
is nothing that a few [t a a] can't fix.)

> this is a nice point for a feature request of an internal [initbang].

But nice points don't make features happen.

> anyway it doesn't mean that things are impossible... they just require 
> you much thinking.

Well, my main point was not about impossibility, it was about some Pd 
abstractions being so troublesome that it would just be easier to write 
them in C instead.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec


More information about the Pd-dev mailing list