[PD] arguments not passed to an external
adrcki at gmail.com
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
> 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
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  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:
> 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;
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!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list