[PD] "get" method for Pd
Jonathan Wilkes
jancsika at yahoo.com
Fri Nov 18 17:53:22 CET 2011
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Thomas Grill <gr at grrrr.org>
> Cc: pd-list at iem.at; Miller Puckette <msp at ucsd.edu>; IOhannes m zmoelnig <zmoelnig at iem.at>
> Sent: Friday, November 18, 2011 10:16 AM
> Subject: Re: [PD] "get" method for Pd
>
>
> This is more like iemguts: properties of abstractions. Jonathan's proposal
> includes that, but also global things. IMHO, iemguts is the most Pd-ish because
> its a library of simple objects rather than a single absattr mega-object with
> attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value
syntax when it was sitting in a previous version of pd extended but that's all.
What I'm really after are some simple, core features that allow the user to
access simple, core data about the pd instance and canvas instance(s).
For the pd instance the most obvious starting point is the version-- the simplest
way is what I proposed about sending a query to the pd and
getting a response with a [receive pd]. Miller wants to avoid this approach
for readability reasons, so if there's a better approach I'd be interested in
hearing it. At the least it should have these features:
* ability to return all data with a single bang/get/whatever message. One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
* clear syntax that can be extended to other areas of pd. I like the "get $something" syntax
because one could also use it for getting data from the inlet of an object and outputting it
to a subsidiary outlet. (Other selectors could be used-- that's just my example.)
* for canvases, the user must be able to make a distinction between "this local canvas" and
"all canvases that have this receive symbol". (This is why [namecanvas] isn't obsoleted by
sending to an abstraction's filename prefixed with "pd-".) The only ways I've seen to do this
are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window
method of [pointer]. Using either to query/receive canvas attributes will be wireless, which
evidently isn't what Miller wants.
My idea is to have the pd community build abstractions around whatever way these features
get implemented. Even if one method of getting the core functionality isn't the most readable,
it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable.
If changes to the core functionality need to be made at a later date then the innards of the
abstraction can be modified to fit those revisions without the abstraction's interface being
affected. This way you open up development of these interfaces to the entire Pd userbase,
rather than just people who can code in c.
-Jonathan
>
> .hc
>
> On Nov 18, 2011, at 5:17 AM, Thomas Grill wrote:
>
>> 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~~~
>> <Bild 2.png>
>>
>>
>> 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
>>
>
>
>
> ----------------------------------------------------------------------------
>
> The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list