[PD] arguments not passed to an external

Mon May 26 22:31:27 CEST 2014

On Mon, May 26, 2014 at 5:36 PM, IOhannes m zmoelnig <zmoelnig at iem.at>wrote:

> -----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.
>
Ok, changed that. I actually did it this way cause when I was trying to
compile zexy for vanilla I kept on receiving error messages saying that
m_pd.h is desperately needed, so I tried with and absolute path (still
didn't work, eventually I copied the binaries from Pd-extended into
/Library/Pd/ and set the path in Pd's preferences. Never mind, off topic).

>
> 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".
>
Right, I changed the name of the external and then changed the c file as
well (also the directory where they both lie).

> 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.
>
My main question then is, how do I use these variables in the perform
routine until I start sending signals? I mean, how do I know if there is a
signal connection to the respective inlet of the argument, or not, so I can
choose between variables set with arguments or vectors sent from the dsp
method? Is there a method to tell this?

>
>
> - - 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).
>
I've changed the new instance routine and now it's like this:
void *powSine_lookup_new(t_symbol *s, int argc, t_atom *argv)
And using post() as you recommended, if I create an object like this
[powSine_lookup~ 220 0.5], I get some weird characters in Pd's console,
more precisely this: Ü@|`ßÿ¿$j
Though I'm not sure if I'm doing it right. I do the following:
In the beginning of the new instance routine I set three variables of type
char to use in post(), like this:
char frequency, power, args;

and just before I return the pointer to the new object at the end of the
routine, I type the following:
frequency = (char) x->x_frequency;
power = (char) x->x_power;
args = (char) argc;
post(&args);
post(&frequency);
post(&power);

should this really print the number of arguments and the actual arguments?

> 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.
>
Should I do (t_method)powSine_lookup_new instead?

>
>
> 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.
>
Thanks for the help!

>
>
> 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-----
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140526/0a834332/attachment-0001.html>