On Mon, May 26, 2014 at 5:36 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list