I'm building an external (my very first one) and it's working as expected, only the arguments I type when I create it are not passed and the variables set to get values from these arguments are set to zero.
The new instance routine prototype is this: void *tabPowSine_new(t_symbol *s, short argc, t_atom argv)
and in this routine I type the following two lines: if(argc >= 1) { x->x_frequency = atom_getfloatarg(0, argc, argv); } if(argc >= 2) { x->x_power = atom_getfloatarg(1, argc, argv); }
but if I create an object like this [tabPowSine~ 220 0.5], the variables x_frequency and x_power (declared in the object structure) won't get these values. As soon as I send a signal or float to the respective inlet, everything works fine.
Also, I get a warning when I type "make" in the terminal, to make the Pd object, which is: tabPowSine~.c:60:32: warning: unused parameter 's' [-Wunused-parameter]
Can I just ommint the t_symbol *s? I'm following Eric Lyon's book for writing externals, and he's passing this symbol pointer (it is a symbol pointer, right?) to the new instance routine...
Final question, so that I don't send three different emails, is it preferable to use a table lookup cosine oscillator than using the cos function in the perform routine? Is there significant difference in the CPU consumption?
What's your setup routine for the external look like?
-Jonathan
On Sunday, May 25, 2014 2:14 PM, Alexandros Drymonitis adrcki@gmail.com wrote:
I'm building an external (my very first one) and it's working as expected, only the arguments I type when I create it are not passed and the variables set to get values from these arguments are set to zero.
The new instance routine prototype is this: void *tabPowSine_new(t_symbol *s, short argc, t_atom argv)
and in this routine I type the following two lines: if(argc >= 1) { x->x_frequency = atom_getfloatarg(0, argc, argv); } if(argc >= 2) { x->x_power = atom_getfloatarg(1, argc, argv); }
but if I create an object like this [tabPowSine~ 220 0.5], the variables x_frequency and x_power (declared in the object structure) won't get these values. As soon as I send a signal or float to the respective inlet, everything works fine.
Also, I get a warning when I type "make" in the terminal, to make the Pd object, which is: tabPowSine~.c:60:32: warning: unused parameter 's' [-Wunused-parameter]
Can I just ommint the t_symbol *s? I'm following Eric Lyon's book for writing externals, and he's passing this symbol pointer (it is a symbol pointer, right?) to the new instance routine...
Final question, so that I don't send three different emails, is it preferable to use a table lookup cosine oscillator than using the cos function in the perform routine? Is there significant difference in the CPU consumption?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, May 25, 2014 at 10:28 PM, Jonathan Wilkes jancsika@yahoo.comwrote:
What's your setup routine for the external look like?
void tabPowSine_tilde_setup(void) { // Initialize the class tabPowSine_class = class_new(gensym("tabPowSine~"), (t_newmethod)tabPowSine_new, (t_method)tabPowSine_free, sizeof(t_tabPowSine), 0, A_GIMME, 0);
// Specify signal input, with automatic float to signal conversion
CLASS_MAINSIGNALIN(tabPowSine_class, t_tabPowSine, x_f);
// Bind the DSP method, which is called when the DACs are turned on
class_addmethod(tabPowSine_class, (t_method)tabPowSine_dsp,
gensym("dsp"), A_CANT, 0);
// Print authorship to Pd window
post("powSine~: Sinewave oscillator raised to a power\n external by
Alexandros Drymonitis"); }
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
-Jonathan
On Sunday, May 25, 2014 2:14 PM, Alexandros Drymonitis adrcki@gmail.com wrote:
I'm building an external (my very first one) and it's working as expected, only the arguments I type when I create it are not passed and the variables set to get values from these arguments are set to zero.
The new instance routine prototype is this: void *tabPowSine_new(t_symbol *s, short argc, t_atom argv)
and in this routine I type the following two lines: if(argc >= 1) { x->x_frequency = atom_getfloatarg(0, argc, argv); } if(argc >= 2) { x->x_power = atom_getfloatarg(1, argc, argv); }
but if I create an object like this [tabPowSine~ 220 0.5], the variables x_frequency and x_power (declared in the object structure) won't get these values. As soon as I send a signal or float to the respective inlet, everything works fine.
Also, I get a warning when I type "make" in the terminal, to make the Pd object, which is: tabPowSine~.c:60:32: warning: unused parameter 's' [-Wunused-parameter]
Can I just ommint the t_symbol *s? I'm following Eric Lyon's book for writing externals, and he's passing this symbol pointer (it is a symbol pointer, right?) to the new instance routine...
Final question, so that I don't send three different emails, is it preferable to use a table lookup cosine oscillator than using the cos function in the perform routine? Is there significant difference in the CPU consumption?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote:
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? Â (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote:
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
I don't see anything in the code that would keep [dsp(--[osc~] from triggering this "dsp" message to the signal object.
Indeed, when I specify A_CANT as the "dsp" arg type for [osc~] and recompile it still crashes.
So that may be the policy, but the design doesn't keep the message from being dispatched.
-Jonathan
On Monday, May 26, 2014 1:32 PM, Miller Puckette msp@ucsd.edu wrote:
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote:
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
Aha... DOUBLE fail on my part - I wasn't enforcing A_CANT and anyhow almost none fo teh tlde objects were using it! Just goes to show - if yuo've never tested something it probably doesn't work.
Should be fixed in vanilla git repo now.
cheers M
On Mon, May 26, 2014 at 11:17:40AM -0700, Jonathan Wilkes wrote:
I don't see anything in the code that would keep [dsp(--[osc~] from triggering this "dsp" message to the signal object.
Indeed, when I specify A_CANT as the "dsp" arg type for [osc~] and recompile it still crashes.
So that may be the policy, but the design doesn't keep the message from being dispatched.
-Jonathan
On Monday, May 26, 2014 1:32 PM, Miller Puckette msp@ucsd.edu wrote:
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? Â (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote: Â
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
Is there a script to change the rest of svn?
Also the externals howto should be changed to use A_CANT instead of zero.
-Jonathan
On Monday, May 26, 2014 3:00 PM, Miller Puckette msp@ucsd.edu wrote:
Aha... DOUBLE fail on my part - I wasn't enforcing A_CANT and anyhow almost none fo teh tlde objects were using it! Just goes to show - if yuo've never tested something it probably doesn't work.
Should be fixed in vanilla git repo now.
cheers M
On Mon, May 26, 2014 at 11:17:40AM -0700, Jonathan Wilkes wrote:
I don't see anything in the code that would keep [dsp(--[osc~] from triggering this "dsp" message to the signal object.
Indeed, when I specify A_CANT as the "dsp" arg type for [osc~] and recompile it still crashes.
So that may be the policy, but the design doesn't keep the message from being dispatched.
-Jonathan
On Monday, May 26, 2014 1:32 PM, Miller Puckette msp@ucsd.edu wrote:
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote:
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
I wouldn't dare unleash a script on SVN - I think it's wiser to leave this up to whomever is maintaining individual packages.
Same for whomever is watching over the howto (it's not my work at all, although I'm delighted it's there! )
M
On Mon, May 26, 2014 at 12:22:15PM -0700, Jonathan Wilkes wrote:
Is there a script to change the rest of svn?
Also the externals howto should be changed to use A_CANT instead of zero.
-Jonathan
On Monday, May 26, 2014 3:00 PM, Miller Puckette msp@ucsd.edu wrote:
Aha... DOUBLE fail on my part - I wasn't enforcing A_CANT and anyhow almost none fo teh tlde objects were using it! Just goes to show - if yuo've never tested something it probably doesn't work.
Should be fixed in vanilla git repo now.
cheers M
On Mon, May 26, 2014 at 11:17:40AM -0700, Jonathan Wilkes wrote:
I don't see anything in the code that would keep [dsp(--[osc~] from triggering this "dsp" message to the signal object.
Indeed, when I specify A_CANT as the "dsp" arg type for [osc~] and recompile it still crashes.
So that may be the policy, but the design doesn't keep the message from being dispatched.
-Jonathan
On Monday, May 26, 2014 1:32 PM, Miller Puckette msp@ucsd.edu wrote: Â
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? Â (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote: Â
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well the maintainer on a lot of it is Hans, and I doubt he wants to do it by hand.
-Jonathan
On Monday, May 26, 2014 4:05 PM, Miller Puckette msp@ucsd.edu wrote:
I wouldn't dare unleash a script on SVN - I think it's wiser to leave this up to whomever is maintaining individual packages.
Same for whomever is watching over the howto (it's not my work at all, although I'm delighted it's there! )
M
On Mon, May 26, 2014 at 12:22:15PM -0700, Jonathan Wilkes wrote:
Is there a script to change the rest of svn?
Also the externals howto should be changed to use A_CANT instead of zero.
-Jonathan
On Monday, May 26, 2014 3:00 PM, Miller Puckette msp@ucsd.edu wrote:
Aha... DOUBLE fail on my part - I wasn't enforcing A_CANT and anyhow almost none fo teh tlde objects were using it! Just goes to show - if yuo've never tested something it probably doesn't work.
Should be fixed in vanilla git repo now.
cheers M
On Mon, May 26, 2014 at 11:17:40AM -0700, Jonathan Wilkes wrote:
I don't see anything in the code that would keep [dsp(--[osc~] from triggering this "dsp" message to the signal object.
Indeed, when I specify A_CANT as the "dsp" arg type for [osc~] and recompile it still crashes.
So that may be the policy, but the design doesn't keep the message from being dispatched.
-Jonathan
On Monday, May 26, 2014 1:32 PM, Miller Puckette msp@ucsd.edu wrote:
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote:
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So probably best just to leave it unfixed. I think lots of folks maintaining librares wouldn't want someone else to come in and edit stuff for them.
cheers M
On Mon, May 26, 2014 at 01:37:31PM -0700, Jonathan Wilkes wrote:
Well the maintainer on a lot of it is Hans, and I doubt he wants to do it by hand.
-Jonathan
On Monday, May 26, 2014 4:05 PM, Miller Puckette msp@ucsd.edu wrote:
I wouldn't dare unleash a script on SVN - I think it's wiser to leave this up to whomever is maintaining individual packages.
Same for whomever is watching over the howto (it's not my work at all, although I'm delighted it's there! )
M
On Mon, May 26, 2014 at 12:22:15PM -0700, Jonathan Wilkes wrote:
Is there a script to change the rest of svn?
Also the externals howto should be changed to use A_CANT instead of zero.
-Jonathan
On Monday, May 26, 2014 3:00 PM, Miller Puckette msp@ucsd.edu wrote: Â
Aha... DOUBLE fail on my part - I wasn't enforcing A_CANT and anyhow almost none fo teh tlde objects were using it! Just goes to show - if yuo've never tested something it probably doesn't work.
Should be fixed in vanilla git repo now.
cheers M
On Mon, May 26, 2014 at 11:17:40AM -0700, Jonathan Wilkes wrote:
I don't see anything in the code that would keep [dsp(--[osc~] from triggering this "dsp" message to the signal object.
Indeed, when I specify A_CANT as the "dsp" arg type for [osc~] and recompile it still crashes.
So that may be the policy, but the design doesn't keep the message from being dispatched.
-Jonathan
On Monday, May 26, 2014 1:32 PM, Miller Puckette msp@ucsd.edu wrote: Â
No, the A_CANT will ensure that the message never gets sent to the object (because typechecking fails)
You can of course send the message from C, but anyone's allowed to crash Pd by introducing faulty C code :)
M
On Mon, May 26, 2014 at 10:23:36AM -0700, Jonathan Wilkes wrote:
Is that by policy or design?
In other words, if I send a msd [dsp crash_my_pd( to a signal object that defines its dsp method args using A_CANT, will it still crash? Â (Not at a machine with Pd or I'd try it myself.)
-Jonathan
On Monday, May 26, 2014 1:06 PM, Miller Puckette msp@ucsd.edu wrote: Â
Just to answer one sprcific question here...
Lyon's book explaing what A_GIMME does, but not A_CANT. I checked m_pd.h a bit but didn't make much out of it. It is there where the problem lies?
A_CANT is used when an object receives a message but the arguments can't be safely typechecked by Pd - so these messages are refued if sent by the patch, but friendly C code can call them using a lower-level mechanism.
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2014-05-25 14:10, Alexandros Drymonitis wrote:
I'm building an external (my very first one) and it's working as expected, only the arguments I type when I create it are not passed and the variables set to get values from these arguments are set to zero.
The new instance routine prototype is this: void *tabPowSine_new(t_symbol *s, short argc, t_atom argv)
Should be void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv) , as argv is an array of exactly argc pointers to t_atoms.
and in this routine I type the following two lines: if(argc >= 1) { x->x_frequency = atom_getfloatarg(0, argc, argv); } if(argc >= 2) { x->x_power = atom_getfloatarg(1, argc, argv); }
but if I create an object like this [tabPowSine~ 220 0.5], the variables x_frequency and x_power (declared in the object structure) won't get these values. As soon as I send a signal or float to the respective inlet, everything works fine.
Also, I get a warning when I type "make" in the terminal, to make the Pd object, which is: tabPowSine~.c:60:32: warning: unused parameter 's' [-Wunused-parameter]
Can I just ommint the t_symbol *s?
That's normal and not important.
I'm following Eric Lyon's book for writing externals, and he's passing this symbol pointer (it is a symbol pointer, right?) to the new instance routine...
Final question, so that I don't send three different emails, is it preferable to use a table lookup cosine oscillator than using the cos function in the perform routine? Is there significant difference in the CPU consumption?
In the past the table was faster, nowadays it may not be if fetching the table causes page faults, which it will if it's a large, precise table.
Martin
On Mon, May 26, 2014 at 1:04 AM, Martin Peach martin.peach@sympatico.cawrote:
On 2014-05-25 14:10, Alexandros Drymonitis wrote:
I'm building an external (my very first one) and it's working as expected, only the arguments I type when I create it are not passed and the variables set to get values from these arguments are set to zero.
The new instance routine prototype is this: void *tabPowSine_new(t_symbol *s, short argc, t_atom argv)
Should be void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv) , as argv is an array of exactly argc pointers to t_atoms.
I mistyped it, sorry. It is like this actually..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
fgamsdr IOhannes
On Mon, May 26, 2014 at 11:28 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
It was shown this way in Lyon's book, no idea why, or what it should be. Tried with an int though and it still won't work. Is it in the setup function or the perform routine? I've read that Pd cannot know whether an object's inlet has been connected to another object, so how can I use variables which have their values set by creation arguments, instead of vectors arriving at the object's inlets?
My perform routine starts as follows: t_int *powSine_perform(t_int *w) { // Copy the object pointer t_powSine *x = (t_powSine *) (w[1]);
// Copy signal vector pointers
t_float *frequency = (t_float *) (w[2]);
t_float *phase_mod = (t_float *) (w[3]);
t_float *power = (t_float *) (w[4]);
t_float *out = (t_float *) (w[5]);
// Copy the signal vector size
t_int n = w[6];
And then I set some local variables and run the while loop for each sample. The while loop is using *frequency and *power for its calculations. Since Pd cannot know if the object is connected to another object, how can I use x->x_frequency and x->x_power (variables declared in the object structure) instead of *frequency and *power, until I start sending signals (or floats) to the respective inlets? A few emails further up in this thread I've posted the setup function as well, I'm posting it again: void powSine_tilde_setup(void) { // Initialize the class powSine_class = class_new(gensym("powSine~"), (t_newmethod)powSine_new, 0, sizeof(t_powSine), 0, A_GIMME, 0);
// Specify signal input, with automatic float to signal conversion
CLASS_MAINSIGNALIN(powSine_class, t_powSine, x_f);
// Bind the DSP method, which is called when the DACs are turned on
class_addmethod(powSine_class, (t_method)powSine_dsp,
gensym("dsp"), A_CANT, 0);
// Bind the method to receive a float in the last inlet (control)
to reset the phase class_addmethod(powSine_class, (t_method)powSine_ft1, gensym("ft1"), A_FLOAT, 0);
// Print authorship to Pd window
post("powSine~: Sinewave oscillator raised to a power\n external by
Alexandros Drymonitis"); } I've added a control inlet to set the oscillator's phase which is working fine (I've kind of copied the code from [phasor~]'s code). That wasn't included in the previous email.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTgvsuAAoJELZQGcR/ejb4wHcP/jFL24R1nT6lh46fw04EycEw DDLP8vsElpyYkJ73cT9s5cjP+in9CayqxMB/GzMst0jOKByibSvrO8oRm7WmEdo8 7tWaF+ZClvAO8ksAbe8P4Ir9DxHH7lHMYhJJxfebgbUY9UFAcDUTqCFfEjUQYC64 Mb8P0a/duI9vXwmbVhAbx+DRFjh4qY60t+Jhan3EYlQBmi25Z1QnzzJdEHje0N2K fIqSArkOau4xKeah6hKPTcYukh/BTHGOtX8Zq1aEfmWjwhEYBmwpkaAwdY4dsAts 9TZIrmG+HGQKSusJN1cAPWb8WubwFzwh6VO4QGcaaf6ftmE6FLM0B0mimhnLkni3 lyT9pKNKl6zRDc85DY90PpCnuvQJlGTG5PYi698lC102rJsgHXz4pghCdK/X3v22 UjBPvGXUx4ScnFl1+6rwmnzS5Xdr8Aw54xFa+1D8E1UtANwNovi9C4KEP/XKPRri s+EIKnKuTMsc4+tUsuQdysm2SIZDvOxIsm3eI0+mEeu6g4KZZC8Bb+T7sA8BSZLp FpOo/5wEuI6RzvmKj5Syx5TRwfol4XzVBRYfyf15lmgi+IiXy3PAtTi7dPtBSGlL FGCSOxTrpoBWsieSEC7EXgKvQCC5o80QfBnxXmoJoeG7OjP7OF+fsfrZ+0GiDVeh j16bDOwyuxmgMYT28ld2 =Ag7/ -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 11:59, Alexandros Drymonitis wrote:
On Mon, May 26, 2014 at 11:28 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
It was shown this way in Lyon's book, no idea why, or what it should be.
it should be int32.
could you post (a link to) your complete external? that would be easier to read.
fgmasdr IOhannes
PS: there's also the pd-dev mailinglist for questions targetted at development. though i see that your case is somewhere in between pd-list and pd-dev
On Mon, May 26, 2014 at 2:57 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 11:59, Alexandros Drymonitis wrote:
On Mon, May 26, 2014 at 11:28 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
It was shown this way in Lyon's book, no idea why, or what it should be.
it should be int32.
could you post (a link to) your complete external? that would be easier to read.
Here you go: https://github.com/alexandros301/powSine-/blob/master/powSine~.c
fgmasdr IOhannes
PS: there's also the pd-dev mailinglist for questions targetted at development. though i see that your case is somewhere in between pd-list and pd-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTgywPAAoJELZQGcR/ejb4PW8P/0K7IEW81vdNtuzTCtVeIKlK NBuAzxeLpTnaJL4Z/TW/T/SlXmGJKJu1QuRoMcBhDPBN3oalsl5p5EFSw0o5XPbG c+4MEogSJr++mOxN4mrbuRcyvy2N/AjMEqNKTNtIJqlI+F4mistJ3+qMeLlLcdFo oAE3QNX/5KykL2j+hdWeBhMZdGTKfvAx5qX0nQ9tL2B3DJoHjzvjGIWUfG5wMAqr acra2UspK0Qu6jj3PNK99E/qH+GZmqxcE1qT4sOPqZ/N/rECfQXxZFNf3IAhxyYd RrrXPrHmRwiCDPG/mSaT8d7wo9MqIFT483Q+NKHoaUgpXNsFJIifYnRZMXP9Y4W6 ExfFVDOg1vv5uZ9axprmBnFPJT4c4zG5eV2z3WgZCVlC0a3cIIa2YBI8bLKw1QvX C4YVicrG99lpUqYnD5wAumfWXQ+kUAYvBnezXiMGwakkVNhHWgMHRPU+RhQR01B7 neKyFUw6ynq3l/0AC40x31S9b8zCWlnnumFY5Ctwo+ZVjUtT9+jto0YRZs+3gvnO NYXDJPBR+Wikas29kDZ2GQTnievUb+w3AkFLhPbTra5TgDVIbJjjP/nPOb2ArDk3 pu406G/s8/b2Lqj0xxIFDONyPnZOKCb8fAZyw8KIIP2VoO0MbbtU/MtX0Oxth1Bn FwXGudRZ8qLHvfS8k5SB =yUcv -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----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.
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". 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.
- 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). 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.
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.
fgmasd IOhannes
[1] https://svn.code.sf.net/p/pure-data/svn/trunk/externals/template/Makefile
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
But for whatever reason, nearly all discussion-- and _especially_ discussion related to the development of Pd itself-- happens on the user list. So just continue to send to the user list.
-Jonathan
On Monday, May 26, 2014 8:00 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 11:59, Alexandros Drymonitis wrote:
On Mon, May 26, 2014 at 11:28 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
It was shown this way in Lyon's book, no idea why, or what it should be.
it should be int32.
could you post (a link to) your complete external? that would be easier to read.
fgmasdr IOhannes
PS: there's also the pd-dev mailinglist for questions targetted at development. though i see that your case is somewhere in between pd-list and pd-dev
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/26/2014 04:28 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
I see no good reason to use short here, either.
But I have to admit I am now curious-- what problem would it cause in this specific case? The number of args to the object will certainly be within the range of short, no?
-Jonathan
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTgvsuAAoJELZQGcR/ejb4wHcP/jFL24R1nT6lh46fw04EycEw DDLP8vsElpyYkJ73cT9s5cjP+in9CayqxMB/GzMst0jOKByibSvrO8oRm7WmEdo8 7tWaF+ZClvAO8ksAbe8P4Ir9DxHH7lHMYhJJxfebgbUY9UFAcDUTqCFfEjUQYC64 Mb8P0a/duI9vXwmbVhAbx+DRFjh4qY60t+Jhan3EYlQBmi25Z1QnzzJdEHje0N2K fIqSArkOau4xKeah6hKPTcYukh/BTHGOtX8Zq1aEfmWjwhEYBmwpkaAwdY4dsAts 9TZIrmG+HGQKSusJN1cAPWb8WubwFzwh6VO4QGcaaf6ftmE6FLM0B0mimhnLkni3 lyT9pKNKl6zRDc85DY90PpCnuvQJlGTG5PYi698lC102rJsgHXz4pghCdK/X3v22 UjBPvGXUx4ScnFl1+6rwmnzS5Xdr8Aw54xFa+1D8E1UtANwNovi9C4KEP/XKPRri s+EIKnKuTMsc4+tUsuQdysm2SIZDvOxIsm3eI0+mEeu6g4KZZC8Bb+T7sA8BSZLp FpOo/5wEuI6RzvmKj5Syx5TRwfol4XzVBRYfyf15lmgi+IiXy3PAtTi7dPtBSGlL FGCSOxTrpoBWsieSEC7EXgKvQCC5o80QfBnxXmoJoeG7OjP7OF+fsfrZ+0GiDVeh j16bDOwyuxmgMYT28ld2 =Ag7/ -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2014-05-26 19:03, Jonathan Wilkes wrote:
On 05/26/2014 04:28 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
I see no good reason to use short here, either.
But I have to admit I am now curious-- what problem would it cause in this specific case? The number of args to the object will certainly be within the range of short, no?
I think because Pd doesn't know how any particular 'new' routine is declared, it just passes the parameters the same way for every object's 'new'. Also the c compiler doesn't know that the 'new' routine must take a certain form, so you don't get any errors until it actually runs. (this could probably be fixed with a typedef for a Pd 'new' routine) In the remote past, short and int were the same thing, but as processors evolve, int gradually gets longer while short stays short.
Martin
On 05/26/2014 07:50 PM, Martin Peach wrote:
On 2014-05-26 19:03, Jonathan Wilkes wrote:
On 05/26/2014 04:28 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
I see no good reason to use short here, either.
But I have to admit I am now curious-- what problem would it cause in this specific case? The number of args to the object will certainly be within the range of short, no?
I think because Pd doesn't know how any particular 'new' routine is declared, it just passes the parameters the same way for every object's 'new'.
That means it's guaranteed to pass an int argc. As long as it's within short's range C should be able to shave it into a short, right?
Also the c compiler doesn't know that the 'new' routine must take a certain form, so you don't get any errors until it actually runs. (this could probably be fixed with a typedef for a Pd 'new' routine) In the remote past, short and int were the same thing, but as processors evolve, int gradually gets longer while short stays short.
But short isn't going to get shorter. So how is a constructor that expects A_GIMME to have an argc of "2" going to get into trouble?
-Jonathan
Martin
On 2014-05-26 20:30, Jonathan Wilkes wrote:
On 05/26/2014 07:50 PM, Martin Peach wrote:
On 2014-05-26 19:03, Jonathan Wilkes wrote:
On 05/26/2014 04:28 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
I see no good reason to use short here, either.
But I have to admit I am now curious-- what problem would it cause in this specific case? The number of args to the object will certainly be within the range of short, no?
I think because Pd doesn't know how any particular 'new' routine is declared, it just passes the parameters the same way for every object's 'new'.
That means it's guaranteed to pass an int argc. As long as it's within short's range C should be able to shave it into a short, right?
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.
Martin
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. 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. Thanks
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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.
Martin
On Tue, May 27, 2014 at 6:19 PM, Martin Peach martin.peach@sympatico.cawrote:
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 anint. (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.
I thought about that, but I do need to send zeros to the vectors some times (for example, raising a signal to a power, raising to the zeroth power will yield a DC of 1, which might be useful sometimes). Of course I can send signals with offsets and subtract the offset in the code, but I don't think this is good design. I'd rather not be able to use arguments.
Martin
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.
I thought about that, but I do need to send zeros to the vectors some times (for example, raising a signal to a power, raising to the zeroth power will yield a DC of 1, which might be useful sometimes). Of course I can send signals with offsets and subtract the offset in the code, but I don't think this is good design. I'd rather not be able to use arguments.
Well, it's not pretty, but you can store the location of the inlet:
x->x_inlet1 = signalinlet_new(...)
and then pass it a message like this:
pd_vmess((t_pd *)x->x_inlet1, &s_float, "f", f);
I want to add an API to allow objects to find out which signal inlets are actually connected (so you can write more efficient versions in case they aren't) but haven't figured out how to do this cleanly yet.
cheers Miller
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-27 05:22, Martin Peach 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.
the order of arguments is system dependent as well. so it might have the "int argc" before of after the "t_symbol*s".
fgmsdf IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-27 01:03, Jonathan Wilkes wrote:
On 05/26/2014 04:28 AM, IOhannes m zmoelnig wrote: On 2014-05-26 09:35, Alexandros Drymonitis wrote:
void *tabPowSine_new(t_symbol *s, short argc, t_atom *argv)
short argc? why short?
this *must* be int (32bit!).
I see no good reason to use short here, either.
But I have to admit I am now curious-- what problem would it cause in this specific case? The number of args to the object will certainly be
i was trying to explain that in my other longish mail with all those hexnumbers.
fgamsdr IOhannes
-
Alexandros Drymonitis -
Alexandros Drymonitis via Pd-list -
IOhannes m zmoelnig -
Jonathan Wilkes -
Martin Peach -
Martin Peach via Pd-list
-
Miller Puckette -
Miller Puckette via Pd-list