[PD] arguments not passed to an external

[Martin Peach]

On 2014-05-25 14:10, Alexandros Drymonitis wrote:
> I'm building an external (my very first one) and it's working as
> expected, only the arguments I type when I create it are not passed and
> the variables set to get values from these arguments are set to zero.
>
> The new instance routine prototype is this:
> void *tabPowSine_new(t_symbol *s, short argc, t_atom argv)

Should be
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
, as argv is an array of exactly argc pointers to t_atoms.

>
> and in this routine I type the following two lines:
> if(argc >= 1) { x->x_frequency = atom_getfloatarg(0, argc, argv); }
> if(argc >= 2) { x->x_power = atom_getfloatarg(1, argc, argv); }
>
> but if I create an object like this [tabPowSine~ 220 0.5], the variables
> x_frequency and x_power (declared in the object structure) won't get
> these values. As soon as I send a signal or float to the respective
> inlet, everything works fine.
>
> Also, I get a warning when I type "make" in the terminal, to make the Pd
> object, which is:
> tabPowSine~.c:60:32: warning: unused parameter 's' [-Wunused-parameter]
>
> Can I just ommint the t_symbol *s?


That's normal and not important.


> I'm following Eric Lyon's book for writing externals, and he's passing
> this symbol pointer (it is a symbol pointer, right?) to the new instance
> routine...
>
> Final question, so that I don't send three different emails, is it
> preferable to use a table lookup cosine oscillator than using the cos
> function in the perform routine? Is there significant difference in the
> CPU consumption?

In the past the table was faster, nowadays it may not be if fetching the 
table causes page faults, which it will if it's a large, precise table.

Martin