[PD] A_DEFSYM/A_SYMBOL A_DEFFLOAT/A_FLOAT differences?

[Christof Ressi]

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 at iem.at>
> An: pd-list at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>