----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@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@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