i just noticed that there is a discrepancy between passed arguments (dsp_add) and how you interpret them in the perform()-routine: while you are passing the sp[1]-s_vec as the "3rd" argument to the perform routine, it is somehow interpreted as "int n2".
Its true, my inlet/outlet requests look like this:
//One signal inlet there by default inlet_new(&ref->x_obj, &ref->x_obj.ob_pd, &s_float, &s_float); //bin inlet outlet_new(&ref->x_obj, &s_float); //bin value outlet
but I dont know how to request anything but signal vectors, as the counter object example doesnt have a dsp function. How do I request the following?
void fftbin_tilde_dsp(t_fftbin *ref, t_signal **sp) { dsp_add(fftbin_tilde_perform, 5, ref, sp[0]->s_vec, control rate float inlet, control rate float outlet, sp[0]->s_n); }
Thanks for your help!
-thewade
Zitiere thewade pdman@aproximation.org:
probably you should have a look at objects that provide a similar I/O-interface like yours and copy'n'paste from that.
one remark: mixing dsp and message inlets is no problem, but you clearly haven't got the concept behind it ;-) your dsp_add() should definitely look like dsp_add(fftbin_tilde_perform, 3, ref, sp[0]->s_vec, sp[0]->s_n); this is: if you want to generate a message-output from one signal input and one message-input. you normally don't pass data from the control-inlet to the perform-routine via a separate argument to the dsp_add but rather it is part of the object's structure ("ref").
furthermore: if you only want to get the n'th element of the signal-vector there are probably other ways (without a need for your own external): e.g: plain pd: [tabsend~] plus [tabread] with zexy: [unpack~] plus [packel] with others i don't know, but i believe there are solutions like stars in the sky.
but of course there is some charme in having written your own external...
mfg.a.dr IOhannes
-
thewade -
zmoelnig＠iem.at