[PD] "get" method for Pd

[Thomas Grill]

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~~~
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bild 2.png
Type: image/png
Size: 91096 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111118/4cc5f96e/attachment-0001.png>
-------------- next part --------------



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