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

[mtx_*~]:
https://svn.code.sf.net/p/pure-data/svn/trunk/externals/iem/iemmatrix/src/mtx_mul~.c




_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list