This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive.
.hc On Nov 18, 2011, at 5:17 AM, Thomas Grill wrote: > Hi all, > i can't read in detail the whole thread, but just a remark: > > I think what you have in mind is close to the idea of patcher attributes in > Max, where you'd have a [pattrhub] object in the abstraction and you can > either ask it for built-in object attributes or [pattr] patcher variables. > > I implemented a similar idea already some years ago with the [absattr] > object, which was extensively used in the vibrez project. It connect to the > concept of flext-style attributes. It's here: > https://svn.grrrr.org/ext/trunk/absattr > > gr~~~ > <Bild 2.png> > > > Am 17.11.2011 um 19:42 schrieb Miller Puckette: > >> This leads to an interesting larger design issue. I've so far resisted >> the idea of using send/receive as a back channel for getting return >> values because of the unreadablity of the resulting patch. So, for >> instance, samplerate~ just puts the sample rate on its outlet. The other >> way, assuming you want locality, would be to confect a unique symbol name >> and then somehow to "receive" it (I'm not even sure that's possible without >> making a self-editing patch). >> >> But there are other situation which seem to beg for the "receive" solution. >> For example you have a complicated object like textfile and you just want to >> query it as to how many lines it has. >> >> although it's migraine-inducing, the neatest solution would be to allow >> "info" style objects to have a right-hand outlet that you connect to, say, >> the "textfile" object like so: >> >> [get linecount( >> | >> | >> [textfile -reference] >> | | >> | [textfile] >> V >> [15< >> >> (where "15" would be the number of lines in the lower textfile object). I >> think Krzystof Chaya did something like this in his wonderful "xeq" object >> (first Pd convention, Graz.) >> >> cheers >> Miller >> >> On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote: >>> >>> I like "info" too, maybe [pd info(. I like Jonathan's ordering because it >>> also makes it easy to have a default receive symbol, so : >>> >>> [;pd info( >>> >>> would dump all the info to: >>> >>> [receive pd] >>> | >>> [route info] >>> >>> Then you could also specify specific things to request: >>> >>> [; pd info dsp( >>> >>> would dump: >>> >>> [receive pd] >>> | >>> [route info] >>> | >>> [route dsp] >>> >>> As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' >>> receive listener, so you direct GUI-related stuff to [send pd-gui]. >>> >>> .hc >>> >>> On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote: >>> >>>> Unfortunately I already used the name "get" for something else but I >>>> agree this should be an object, maybe 'get-info" or even just "info". >>>> It could get and/or set info about the canvas it's in as well as about >>>> other canvases (by name) and Pd globally. >>>> >>>> cheers >>>> Miller >>>> >>>> On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 2011-11-17 15:09, IOhannes m zmoelnig wrote: >>>>>> On 2011-11-17 14:53, Patrice Colet wrote: >>>>>>> Hello, >>>>>>> would this method provide patch window size and position? >>>>>> >>>>>>> [; pd get size pd-mpatch.pd rcv_name( >>>>>>> [; pd get pos pd-mpatch.pd rcv_name( >>>>>> >>>>>> now we are getting close to why i think using "get <rcvname> ..." is >>>>>> better than "get <verb> <rcvname>" >>>>> >>>>> but of course jonathan and roman are right when they say that this is >>>>> not something you would ask "pd" about. >>>>> >>>>> fgamsdr >>>>> IOhannes >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>>>> >>>>> iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx >>>>> nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z >>>>> =XrRZ >>>>> -----END PGP SIGNATURE----- >>>>> >>>> >>>> >>>> >>>>> _______________________________________________ >>>>> [email protected] mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>> >>> >>> ---------------------------------------------------------------------------- >>> >>> Access to computers should be unlimited and total. - the hacker ethic >>> >>> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > ---------------------------------------------------------------------------- The arc of history bends towards justice. - Dr. Martin Luther King, Jr. _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
