Hello list,
What are the differences between A_DEFSYM and A_SYMBOL and also A_DEFFLOAT and A_FLOAT?
In my situation, I'm updating an object that used to take A_DEFSYM as a first argt and A_FLOAT as a second argt, but I want to take a variable number of arguments now so I'm just replacing those with A_GIMME in class_new (and then passing t_symbol *s, int argc, t_atom *argv instead of t_symbol *s, t_floatarg f into the class's _new). Then I'm type-checking each argt of the t_atom by A_SYMBOL and A_FLOAT and getting their contents with atom_getsymbolarg and atom_getfloatarg respectively. However, things seem not to work the same... It could be other bugs I've introduced but could this be also due to going from A_DEFSYM to A_SYMBOL (and perhaps the same for float)? If so, is there a way to typecast to the DEF versions?
Thanks!
Derek
===================== Derek Kwan www.derekxkwan.com
On 05/02/2016 02:30 AM, Derek Kwan wrote:
Hello list,
What are the differences between A_DEFSYM and A_SYMBOL and also A_DEFFLOAT and A_FLOAT?
they fallback to default values if no value is present. e.g. the [float] object has a single A_DEFFLOAT argument. if you forget to provide it, [float] will use a default value of 0 instead (you cannot change the default value). otoh, zexy's [repack] object used a single A_FLOAT argument (iirc). if you forgot to provide it, Pd's object instantiation mechanism would complain about "Bad arguments for message 'repack' to object 'objectmaker'" and refuse to create the object.
In my situation, I'm updating an object that used to take A_DEFSYM as a first argt and A_FLOAT as a second argt,
which does't make sense. since you require the 2nd argument, you obviously always need a firstargument to be present. it should therefore be (A_SYMBOL, A_FLOAT), (A_DFSYMBOL, A_DEFFLOAT) or (A_SYMBOL, A_DEFFLOAT).
but I want to take a variable
number of arguments now so I'm just replacing those with A_GIMME in
which is usually the sanest way to have default values of your own liking (e.g. non-null and non-'')
class_new (and then passing t_symbol *s, int argc, t_atom *argv instead of t_symbol *s, t_floatarg f into the class's _new). Then I'm type-checking each argt of the t_atom by A_SYMBOL and A_FLOAT and getting their contents with atom_getsymbolarg and atom_getfloatarg respectively. However, things seem not to work the same... It could be other bugs I've introduced but could this be also due to going from A_DEFSYM to A_SYMBOL (and perhaps the same for float)? If so, is there a way to typecast to the DEF versions?
there is no need. the callbacks will always be called with real floats resp. symbols. the bug is somewhere else.
gfmadsr IOhannes
I have a slightly related question:
I usually use A_GIMME for multiple creation arguments, but I looked at some code using several A_DEFFLOAT and A_DEFSYMBOL and couldn't get my head around the order in which these are forwarded to the new method.
Take for example the code for [delay] in x_time.c In the setup function it says:
delay_class = class_new(gensym("delay"), (t_newmethod)delay_new, (t_method)delay_free, sizeof(t_delay), 0, A_DEFFLOAT, A_DEFFLOAT, A_DEFSYM, 0);
The new method is called the following way:
static void *delay_new(t_symbol *unitname, t_floatarg f, t_floatarg tempo) { ... }
while I had naively expected it to be this:
static void *delay_new(t_floatarg f, t_floatarg tempo, t_symbol *unitname) { ... }
Why are the creation arguments rearranged and what's the rule for this?
Christof
Gesendet: Montag, 02. Mai 2016 um 07:49 Uhr Von: "IOhannes m zmölnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] A_DEFSYM/A_SYMBOL A_DEFFLOAT/A_FLOAT differences?
On 05/02/2016 02:30 AM, Derek Kwan wrote:
Hello list,
What are the differences between A_DEFSYM and A_SYMBOL and also A_DEFFLOAT and A_FLOAT?
they fallback to default values if no value is present. e.g. the [float] object has a single A_DEFFLOAT argument. if you forget to provide it, [float] will use a default value of 0 instead (you cannot change the default value). otoh, zexy's [repack] object used a single A_FLOAT argument (iirc). if you forgot to provide it, Pd's object instantiation mechanism would complain about "Bad arguments for message 'repack' to object 'objectmaker'" and refuse to create the object.
In my situation, I'm updating an object that used to take A_DEFSYM as a first argt and A_FLOAT as a second argt,
which does't make sense. since you require the 2nd argument, you obviously always need a firstargument to be present. it should therefore be (A_SYMBOL, A_FLOAT), (A_DFSYMBOL, A_DEFFLOAT) or (A_SYMBOL, A_DEFFLOAT).
but I want to take a variable
number of arguments now so I'm just replacing those with A_GIMME in
which is usually the sanest way to have default values of your own liking (e.g. non-null and non-'')
class_new (and then passing t_symbol *s, int argc, t_atom *argv instead of t_symbol *s, t_floatarg f into the class's _new). Then I'm type-checking each argt of the t_atom by A_SYMBOL and A_FLOAT and getting their contents with atom_getsymbolarg and atom_getfloatarg respectively. However, things seem not to work the same... It could be other bugs I've introduced but could this be also due to going from A_DEFSYM to A_SYMBOL (and perhaps the same for float)? If so, is there a way to typecast to the DEF versions?
there is no need. the callbacks will always be called with real floats resp. symbols. the bug is somewhere else.
gfmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 05/02/2016 01:42 PM, Christof Ressi wrote:
Why are the creation arguments rearranged and what's the rule for this?
the rule is: symbols before floats. the reason i don't know, but i suspect that it is historic (API compatibility with ispw/max and ABI compatibility with Pd-0.22)
fgmdar IOhannes
thanks!
Gesendet: Montag, 02. Mai 2016 um 14:09 Uhr Von: "IOhannes m zmölnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] A_DEFSYM/A_SYMBOL A_DEFFLOAT/A_FLOAT differences?
On 05/02/2016 01:42 PM, Christof Ressi wrote:
Why are the creation arguments rearranged and what's the rule for this?
the rule is: symbols before floats. the reason i don't know, but i suspect that it is historic (API compatibility with ispw/max and ABI compatibility with Pd-0.22)
fgmdar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Derek Kwan -
IOhannes m zmölnig