<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 5:36 PM, IOhannes m zmoelnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</div><div class="">On 2014-05-26 14:28, Alexandros Drymonitis wrote:<br>
><br>
>> Here you go:<br>
>> <a href="https://github.com/alexandros301/powSine-/blob/master/powSine~.c" target="_blank">https://github.com/alexandros301/powSine-/blob/master/powSine~.c</a><br>
<br>
</div>thanks.<br>
<br>
a few remarks:<br>
<br>
- - you should *never ever* use the full-path when you #include a file.<br>
it should read<br>
#include "m_pd.h"<br>
and then you should add the proper INCLUDE path to your build-system,<br>
so the compiler can actually find the file.<br></blockquote><div>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).<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
at least, if you ever want your external to be compilable on a machine<br>
that is *not* running Pd-0.45-3 (vanilla) on an OSX computer.<br>
<br>
<br>
- - you should go and make it a habit to name the C-files the same as<br>
your objects. e.g. the code for [powSine_lookup~] should be in a file<br>
"powSine_lookup~.c".<br></blockquote><div>Right, I changed the name of the external and then changed the c file as well (also the directory where they both lie).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
this allows to integrate it very easily with other build-systems, e.g.<br>
the template/Makefile [1] which is already known to be able to compile<br>
on a plethora of systems (at least if you don't use absolute includes :-))<br>
<br>
<br>
having said that, i compiled your external and it behaves as expected.<br>
at least, if i post() the x_frequency and x_power values, they give<br>
the values as specified via the object-arguments.<br>
<br>
some thoughts, what could be the cause of your problems:<br>
<br>
- - i don't know how you tested whether the arguments are passed to the<br>
object. however in your code you ignore the values of x_frequency and<br>
x_power, so it is no wonder that they do not have any effect.<br></blockquote><div>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? <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
- - you are using "short argc" instead of "int argc" as i suggested.<br>
this could indeed be the problem, as C is a very low-level language.<br>
this means, that when the constructor-function "powSine_lookup_new" is<br>
called, it is really only called with the arguments aligned in memory<br>
as Pd expects them, not like you would like to have them.<br>
e.g. really the function callback for the constructor will have<br>
arguments like (in raw bytes):<br>
0x09 0xd0 0x2e 0xb0 0x00 0x00 0x00 0x02 ...<br>
now you are interpreting these bytes according to your<br>
function-definition as "t_symbol*" (a pointer, taking e.g. 4 bytes),<br>
"int" (a number taking 4 bytes) and so on.<br>
which means that you end up with your arguments having the values:<br>
t_symbol*s=0x09d02eb0;<br>
int argc =0x00000002; /* this really is "2" */<br>
(i'm assuming 4 bytes for the t_symbol* pointer, which is only true on<br>
32bit systems; but it saves me some typing with no added info)<br>
now the problem is, that if you assume that argc is of type "short",<br>
then you are really only reading the first 2 bytes (after the<br>
t_symbol*), resulting in:<br>
int argc =0x0000; /* oops, this is "0" */<br>
<br>
you are quite lucky, that argc is indeed 0, as of course the arguments<br>
following the "argc" bytes, will now have a weird offset, so what you<br>
think is your argv is indeed just garbage.<br>
<br>
now the actual order (and alignment) of arguments depends on a number<br>
of things, including your operating system.<br>
but it still holds true, that you cannot just exchange an int16 (aka<br>
"short") for an int32 (aka "int"), in a callback function without<br>
calling for desaster. (no matter if this is what eric's book says).<br></blockquote><div>I've changed the new instance routine and now it's like this:<br>void *powSine_lookup_new(t_symbol *s, int argc, t_atom *argv)<br>
</div><div>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<br></div><div>Though I'm not sure if I'm doing it right. I do the following:<br>
</div><div>In the beginning of the new instance routine I set three variables of type char to use in post(), like this:<br></div><div>char frequency, power, args;<br><br></div><div>and just before I return the pointer to the new object at the end of the routine, I type the following:<br>
frequency = (char) x->x_frequency;<br>power = (char) x->x_power;<br>args = (char) argc;<br>post(&args);<br>post(&frequency);<br>post(&power);<br><br></div><div>should this really print the number of arguments and the actual arguments?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
even more so, if you do a typecast when registering the callback<br>
function (remember that you do cast "powSine_lookup_setup" to<br>
"(t_newmethod)") which will circumvent a whole bunch of type-checking<br>
the compiler could have done for you.<br></blockquote><div>Should I do (t_method)powSine_lookup_new instead? <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
anyhow, a good start to debug such problems, is to check whether the<br>
values you deal with are really the values you expect.<br>
e.g. what is the value of "argc", depending on how many arguments you<br>
pass to the object.<br>
for starters use "post()" to print the values.<br>
then you can learn how to use a debugger, and inspect the context of<br>
your running program.<br></blockquote><div>Thanks for the help! <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
fgmasd<br>
IOhannes<br>
<br>
<br>
[1]<br>
<a href="https://svn.code.sf.net/p/pure-data/svn/trunk/externals/template/Makefile" target="_blank">https://svn.code.sf.net/p/pure-data/svn/trunk/externals/template/Makefile</a><br>
<div class="">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
Comment: Using GnuPG with Icedove - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iQIcBAEBCAAGBQJTg1FrAAoJELZQGcR/ejb4B0MP/0wakGRgV/c3GUB1V923bFVn<br>
+X/XH1/raSgPoio+AXRrYQ0evs1+K7fhrh0nSy2ZBsZk/PzCAkRSoUY6iAifMgDm<br>
Nv7LTTLggY0Z4DAH7nZAyGX2apFvfrEpf2fh2BN/ftuMHGBRqBgnGGbvjKUEUmC8<br>
iwBxezIX4kkp8cHi+hC57+jtv16bcJY4ZmFcGU5rlW59fPJ3UxwYJr7xDmLZTPRU<br>
XzVgRzW7yU60dmszxD94xPvmywX5n+RDr6c41vi0JFN/EgTqxcKCVJpdzyumdt0b<br>
nxSttUmqDY8wk8cGSD+Sh/0nop6dSFWdNUEuAUawBk8UjAFzpBTK/IqkgHq6baN2<br>
zrRfFUKFaqb/5Vm8TolEKq2V3HMxTcgKkn1lwsDuawT2HuEo9FiAIBE/OF/OJW4f<br>
COAfcAS4lWGL65tt+a9+d5ZYNa0uJ4pc6lEgTaAByJI+hwP3rJFmqIBO6suByqJp<br>
cy041FtYwhAfJl9duiMSo246ADnMuZhLWvSwiCjW6flAl5riJFG6dDxpiq2HTuwn<br>
9ssasW+A+k/NqSuUb87N/D2MMmmSgzzMDTxgnO/dRzSsadZmOD0dmKUTvOX78XvR<br>
lV7eA1qq83ToCWhkTcZWPcgoOdEWnXBnvNbaEhc/xE1JQOzMKe5U/GRkXPvCXjpx<br>
OPRWLjpZKqZnblqCJuOJ<br>
=pr8d<br>
<div class=""><div class="h5">-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div></div>