[PD] "get" method for Pd

[Jonathan Wilkes]

----- Original Message -----

> From: Miller Puckette <msp at ucsd.edu>
> To: Hans-Christoph Steiner <hans at at.or.at>
> Cc: pd-list at iem.at; IOhannes m zmoelnig <zmoelnig at iem.at>
> 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-----
>>  >> 
>>  > 
>>  > 
>>  > 
>>  >> _______________________________________________
>>  >> Pd-list at iem.at mailing list
>>  >> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>>  > 
>>  > 
>>  > _______________________________________________
>>  > Pd-list at 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
>> 
>> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>