[PD] arguments not passed to an external

Martin Peach via Pd-list pd-list at lists.iem.at
Tue May 27 17:19:07 CEST 2014

On 2014-05-27 04:00, Alexandros Drymonitis wrote:
>     The parameters are passed on the stack, so if it's a little-endian
>     machine the first two bytes will be the same for a short as for an int.
>     (Big-endians would think argc was zero). The problem arises when the
>     called routine looks for the first argv which it expects to find
>     right after the short argc on the stack. The caller put a four-byte
>     int there so the next two bytes will be zero and all the pointers to
>     the argvs will be wrong.
> Since my laptop's processor is an Intel Core 2, it's a little edian one,
> right? How can I make my code versatile so that it can compile on either
> little or big endian machines? I'm reading Pd's source code ([phasor~]'s
> code, for example) but it's beyond my understanding. I kind of
> understand the beginning of d_osc.c where the code will try to determine
> the endianess of the machine, but when it comes to sorting arguments out
> depending on the endianess, I'm at loss.

You don't need to know the endianness of the machine. The compiler and 
linker take care of that. (You could use the htons() function on a test 
short like 1234 to see if the result is the same as the input. If they 
are the same then you have a big-endian machine.)
As long as you declare your 'new' routine with argc as an int it will 
just work.

> Another important question I still have is, how do I determine whether
> there is a signal coming in the object's inlets, so I know whether to
> use the values passed via arguments, or the vectors passed from the dsp
> method. I'm asking the same thing over and over again...I'll stop for now.

I think if you get all zeros on the vector for the inlet you can assume 
it's not connected. So use the argument values until you get non-zero on 
the inlet vectors.


More information about the Pd-list mailing list