[PD] arguments not passed to an external

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2014-05-26 14:28, Alexandros Drymonitis wrote:
> 
>> Here you go: 
>> https://github.com/alexandros301/powSine-/blob/master/powSine~.c

thanks.

a few remarks:

- - you should *never ever* use the full-path when you #include a file.
it should read
 #include "m_pd.h"
and then you should add the proper INCLUDE path to your build-system,
so the compiler can actually find the file.

at least, if you ever want your external to be compilable on a machine
that is *not* running Pd-0.45-3 (vanilla) on an OSX computer.


- - you should go and make it a habit to name the C-files the same as
your objects. e.g. the code for [powSine_lookup~] should be in a file
"powSine_lookup~.c".
this allows to integrate it very easily with other build-systems, e.g.
the template/Makefile [1] which is already known to be able to compile
on a plethora of systems (at least if you don't use absolute includes :-))


having said that, i compiled your external and it behaves as expected.
at least, if i post() the x_frequency and x_power values, they give
the values as specified via the object-arguments.

some thoughts, what could be the cause of your problems:

- - i don't know how you tested whether the arguments are passed to the
object. however in your code you ignore the values of x_frequency and
x_power, so it is no wonder that they do not have any effect.


- - you are using "short argc" instead of "int argc" as i suggested.
this could indeed be the problem, as C is a very low-level language.
this means, that when the constructor-function "powSine_lookup_new" is
called, it is really only called with the arguments aligned in memory
as Pd expects them, not like you would like to have them.
e.g. really the function callback for the constructor will have
arguments like (in raw bytes):
  0x09 0xd0 0x2e 0xb0 0x00 0x00 0x00 0x02 ...
now you are interpreting these bytes according to your
function-definition as "t_symbol*" (a pointer, taking e.g. 4 bytes),
"int" (a number taking 4 bytes) and so on.
which means that you end up with your arguments having the values:
  t_symbol*s=0x09d02eb0;
  int argc  =0x00000002; /* this really is "2" */
(i'm assuming 4 bytes for the t_symbol* pointer, which is only true on
32bit systems; but it saves me some typing with no added info)
now the problem is, that if you assume that argc is of type "short",
then you are really only reading the first 2 bytes (after the
t_symbol*), resulting in:
  int argc =0x0000; /* oops, this is "0" */

you are quite lucky, that argc is indeed 0, as of course the arguments
following the "argc" bytes, will now have a weird offset, so what you
think is your argv is indeed just garbage.

now the actual order (and alignment) of arguments depends on a number
of things, including your operating system.
but it still holds true, that you cannot just exchange an int16 (aka
"short") for an int32 (aka "int"), in a callback function without
calling for desaster. (no matter if this is what eric's book says).
even more so, if you do a typecast when registering the callback
function (remember that you do cast "powSine_lookup_setup" to
"(t_newmethod)") which will circumvent a whole bunch of type-checking
the compiler could have done for you.


anyhow, a good start to debug such problems, is to check whether the
values you deal with are really the values you expect.
e.g. what is the value of "argc", depending on how many arguments you
pass to the object.
for starters use "post()" to print the values.
then you can learn how to use a debugger, and inspect the context of
your running program.


fgmasd
IOhannes


[1]
https://svn.code.sf.net/p/pure-data/svn/trunk/externals/template/Makefile
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTg1FrAAoJELZQGcR/ejb4B0MP/0wakGRgV/c3GUB1V923bFVn
+X/XH1/raSgPoio+AXRrYQ0evs1+K7fhrh0nSy2ZBsZk/PzCAkRSoUY6iAifMgDm
Nv7LTTLggY0Z4DAH7nZAyGX2apFvfrEpf2fh2BN/ftuMHGBRqBgnGGbvjKUEUmC8
iwBxezIX4kkp8cHi+hC57+jtv16bcJY4ZmFcGU5rlW59fPJ3UxwYJr7xDmLZTPRU
XzVgRzW7yU60dmszxD94xPvmywX5n+RDr6c41vi0JFN/EgTqxcKCVJpdzyumdt0b
nxSttUmqDY8wk8cGSD+Sh/0nop6dSFWdNUEuAUawBk8UjAFzpBTK/IqkgHq6baN2
zrRfFUKFaqb/5Vm8TolEKq2V3HMxTcgKkn1lwsDuawT2HuEo9FiAIBE/OF/OJW4f
COAfcAS4lWGL65tt+a9+d5ZYNa0uJ4pc6lEgTaAByJI+hwP3rJFmqIBO6suByqJp
cy041FtYwhAfJl9duiMSo246ADnMuZhLWvSwiCjW6flAl5riJFG6dDxpiq2HTuwn
9ssasW+A+k/NqSuUb87N/D2MMmmSgzzMDTxgnO/dRzSsadZmOD0dmKUTvOX78XvR
lV7eA1qq83ToCWhkTcZWPcgoOdEWnXBnvNbaEhc/xE1JQOzMKe5U/GRkXPvCXjpx
OPRWLjpZKqZnblqCJuOJ
=pr8d
-----END PGP SIGNATURE-----