Charles Henry wrote: >> course it's a really handy tool. but since I can't look at an object >> inside it's code, there was no way for me to know about it. >> > > That is interesting to know. I didn't know that it was a standard > behavior either.... but since you've brought it up, now I'd like to > know how the code allows this as well. > I wouldn't expect it to be found in each and every external, so I > would assume it is in the Pd code itself, with behavior of non-signal > inlets in general > > (~half hour later) > ... so I tried reading the code for myself, and don't get it.... I > thought I might find it in m_pd.c/m_pd.h , but for the very most part, > the pd data structures go over my head. > all those structs and unions.... and m_pd.h is actually longer than > m_pd.c (seems like m_pd.h is a swiss-army knife of headers/definitions > that applies to more files than one)... blows my mind :P > > I will have to read some more later~ > Chuck > > It's in m_class.c: /* handle "list" messages to Pds without explicit list methods defined. */ static void pd_defaultlist(t_pd *x, t_symbol *s, int argc, t_atom *argv) ... /* if the object is patchable (i.e., can have proper inlets) send it on to obj_list which will unpack the list into the inlets */ else if ((*x)->c_patchable) obj_list((t_object *)x, s, argc, argv); /* otherwise gove up and complain. */ ... /* objects interpret lists by feeding them to the individual inlets. Before you call this check that the object doesn't have a more specific way to handle lists. */ void obj_list(t_object *x, t_symbol *s, int argc, t_atom *argv) ...
Martin _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list