That's a great point, just an [info] object makes a lot of sense. [dsp( | [info] | [route dsp] | [1(
Then there could also be [pd-gui], but unfortunately not [pd]. But about the [textfile] example, it seems to be that the second outlet could be used for general meta information. This is used in lots of other objects and it works quite nicely (see [hid], [comport], etc.) I suppose that would break backwards compatibilty tho... .hc On Nov 17, 2011, at 1:42 PM, Miller Puckette wrote: > 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----- >>>> >>> >>> >>> >>>> _______________________________________________ >>>> 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 >> >> >> ---------------------------------------------------------------------------- >> >> Access to computers should be unlimited and total. - the hacker ethic >> >> ---------------------------------------------------------------------------- Access to computers should be unlimited and total. - the hacker ethic _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list