[PD] "get" method for Pd
Jonathan Wilkes
jancsika at yahoo.com
Thu Nov 17 23:40:10 CET 2011
----- Original Message -----
> From: Miller Puckette <msp at ucsd.edu>
> To: Hans-Christoph Steiner <hans at at.or.at>
> Cc: pd-list at iem.at; IOhannes m zmoelnig <zmoelnig at 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 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
>
More information about the Pd-list
mailing list