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