Does any one know how to write a ~ object that has a variable number signal outlets and inlets? The only thing I've been able to come up with is to have a dsp routine that looks like:
switch(x->n_sigs){ case 3: dsp_add(whatever_tilde_perform, 5, x, sp[0]->s_vec, sp[1]->s_vec, sp[2]->s_vec, sp[0]->s_n); break;
case 4:
dsp_add(whatever_tilde_perform,
6,
x,
sp[0]->s_vec,
sp[1]->s_vec,
sp[2]->s_vec,
sp[3]->s_vec, sp[0]->s_n); break; // so on and so forth...
}
It feels like there should be a better way to do this. Thanks, David
hi dave! check out the dsp_addv function, I think it’s meant for exactly this. I don’t have any code right in front of me… oh wait, I do … I’m pretty sure this works:
void grans_dsp(t_grans *x, t_signal **sp) { int num = x->numinlets + x->numoutlets; t_int **w = x->w; w[0] = (t_int *)x; w[1] = (t_int *)sp[0]->s_n;
int i;
for (i = 0; i < num; i++) {
w[i+2] = (t_int *)sp[i]->s_vec;
}
dsp_addv(grans_perform, num+2, (t_int *)w);
}
hope that’s useful!
cheers, rama
On Aug 30, 2015, at 12:09 PM, David Medine dmedine@ucsd.edu wrote:
Does any one know how to write a ~ object that has a variable number signal outlets and inlets? The only thing I've been able to come up with is to have a dsp routine that looks like:
switch(x->n_sigs){ case 3: dsp_add(whatever_tilde_perform, 5, x, sp[0]->s_vec, sp[1]->s_vec, sp[2]->s_vec, sp[0]->s_n); break;
case 4: dsp_add(whatever_tilde_perform, 6, x, sp[0]->s_vec, sp[1]->s_vec, sp[2]->s_vec, sp[3]->s_vec, sp[0]->s_n); break; // so on and so forth...
}
It feels like there should be a better way to do this. Thanks, David
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/30/2015 09:36 PM, Rama Gottfried wrote:
hi dave! check out the dsp_addv function, I think it’s meant for exactly this. I don’t have any code right in front of me… oh wait, I do … I’m pretty sure this works:
yes, dsp_addv() should do the trick.
anyhow, i found that in most cases i use dsp_add() but don't pass the signal pointers directly, but store them in the objects structure.
see iemmatrix' mtx_*~ code for an example.
gmfdsrt IOhannes
So if I understand correctly, this should always be ok as long as the number of ins and outs is correct:
n = x->x_n_in + x->x_n_out; for(i=0; i<n; i++) x->x_io[i] = sp[i+compat_offset]->s_vec;
and then we don't need to pass the s_vec variables one by one int the call to dsp_add because they are stashed in the object structure and are recoverable there in the 'perform' routine.
This suggests that anytime I change a connection on a ~ object, its 'whatever_tilde_dsp' function gets with the appropriate spot on the **sp pointer array -- which is organized according to the topography of the patch itself.
One question that now arises is why doesn't the perform routine crash if one of its signal inlets/outlets isn't connected? The perform routine always accesses memory behind the signal pointers even if they aren't connected, so there must be something there. Is there some kind of default 'empty' signal that goes into/out of empty slots? I'm just curious.
Thanks for the help, Ramma and IOhannes!
On 8/30/2015 12:47 PM, IOhannes m zmölnig wrote:
On 08/30/2015 09:36 PM, Rama Gottfried wrote:
hi dave! check out the dsp_addv function, I think it’s meant for exactly this. I don’t have any code right in front of me… oh wait, I do … I’m pretty sure this works:
yes, dsp_addv() should do the trick.
anyhow, i found that in most cases i use dsp_add() but don't pass the signal pointers directly, but store them in the objects structure.
see iemmatrix' mtx_*~ code for an example.
gmfdsrt IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd generates a signal filled with zeros for unconnected inlets.
cheers Miller
One question that now arises is why doesn't the perform routine crash if one of its signal inlets/outlets isn't connected? The perform routine always accesses memory behind the signal pointers even if they aren't connected, so there must be something there. Is there some kind of default 'empty' signal that goes into/out of empty slots? I'm just curious.