----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Thomas Grill gr@grrrr.org Cc: pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@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 -
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx
nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list