----- Original Message ----- > From: Miller Puckette <[email protected]> > To: Hans-Christoph Steiner <[email protected]> > Cc: [email protected]; IOhannes m zmoelnig <[email protected]> > Sent: Thursday, November 17, 2011 1:42 PM > Subject: Re: [PD] "get" method for Pd > >T his 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.
I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all. Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user. -Jonathan > 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
