[PD] "get" method for Pd

[Hans-Christoph Steiner]

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 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
>> 
>> 


----------------------------------------------------------------------------

Access to computers should be unlimited and total.  - the hacker ethic