Hi, Charles,
I think it is just the matter of WHERE the code goes.
My understanding (as for now) is that the method registered with gensym("dsp") is called,
anytime when either the block size or sample rate changes or when the signal graph is rebuilt.
so that running this check,
if (x->n != n) x->is_new_or_resized=1;
may be redundant if it is in the DSP chain (typically classname_tilde_perform) compared to including it in the call back function. (typically classname_tilder_dsp).
Someone please correct me if I am wrong.
-- David Shimamoto
On Sat, Jun 14, 2008 at 5:15 PM, Thomas Grill gr@grrrr.org wrote:
Am 14.06.2008 um 18:37 schrieb PSPunch:
That's definitely bad practice. Instead of that you can do the allocation in the "dsp" callback, that's where you add your dsp processing to the signal chain. This callback will be called anytime when either the block size or sample rate changes or when the signal graph is rebuilt.
What is the dsp callback? This is new to me, too.
I had a different approach when it comes to building static arrays that depend on block size. I used three variables in the struct, x->n, x->array_pointer, and x->is_new_or_resized
Then, example use in perform routine:
if (x->n != n) x->is_new_or_resized=1; if (x->is_new_or_resized) { x->is_new_or_resized=0; if (x->array_pointer != NULL) free(x->array_pointer); malloc(x->array_pointer, n); x->n=n; }
So, you can see the problem. It would be useful to know another way.
Chuck
gr~~~
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
PSPunch