Re: [PD] scale from maxlib - undocumented feature
On Tue, 25 Sep 2007, Claude Heiland-Allen wrote: --8-- Unless they arrange otherwise by defining a list method, objects respond to the list message by distributing the arguments of the message to their inlets, except for the first argument which is passed as a float or symbol message to the object proper. --8-- That's not all. They can also arrange otherwise by defining a anything method, which overrides all default behaviours at once. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
This is a standard feature of all obects/externals: If the hot inlet does not accept a list, the first element is sent to the first inlet, the second element to the second inlet, etc... oh, I guess I was missing something all these years You were probably already using it with [line~] and [vline~] etc. yes, because it is written in their documentation that it's supposed to work that way. as far as I remember, I never saw it anywhere else. of 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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
Charles Henry wrote: I will have to read some more later~ http://www-crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s6.4 --8-- Unless they arrange otherwise by defining a list method, objects respond to the list message by distributing the arguments of the message to their inlets, except for the first argument which is passed as a float or symbol message to the object proper. --8-- ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
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
Re: [PD] scale from maxlib - undocumented feature
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote: This is a standard feature of all obects/externals: If the hot inlet does not accept a list, the first element is sent to the first inlet, the second element to the second inlet, etc... oh, I guess I was missing something all these years You were probably already using it with [line~] and [vline~] etc. Once you realize it, you may find it very useful in other places as well. For example it's very handy to add a list of two numbers without unpacking: [1 2( | [+ ] | 3 or to swap numbers: [1 2[ | [swap] | 2 1 or to multiply many numbers with [list-reduce]: [1 2 3 4 5 6 7( | [list-reduce]X[* ] | 5040 or use it with [expr]: [1 2 3 4( | [expr $f1/$f2 + $f3/$f4] | 1.25 Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
On Sun, 23 Sep 2007, João Miguel Pais wrote: I just found out that if a list is sent to a |scale|, all values after the 1st substitute the parameters. The result will be the scaling of the 1st number, but already with the new parameters. Is this intentional, or was it a lucky effect? Maybe it would be better to update the documentation? Think of [scale] being made of two parts: [pack 0 0 0 0 0] | [the_rest] so, scale is a 5-inlet packlike class. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
This is a standard feature of all obects/externals: If the hot inlet does not accept a list, the firs Tom On 9/22/07, João Miguel Pais [EMAIL PROTECTED] wrote: Hi, I just found out that if a list is sent to a |scale|, all values after the 1st substitute the parameters. The result will be the scaling of the 1st number, but already with the new parameters. Is this intentional, or was it a lucky effect? Maybe it would be better to update the documentation? Best, João Miguel Pais -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] scale from maxlib - undocumented feature
This is a standard feature of all obects/externals: If the hot inlet does not accept a list, the first element is sent to the first inlet, the second element to the second inlet, etc... Tom On 9/22/07, João Miguel Pais [EMAIL PROTECTED] wrote: Hi, I just found out that if a list is sent to a |scale|, all values after the 1st substitute the parameters. The result will be the scaling of the 1st number, but already with the new parameters. Is this intentional, or was it a lucky effect? Maybe it would be better to update the documentation? Best, João Miguel Pais -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
