On Tue, 8 Jul 2008, mescalinum@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