[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