[PD] "get" method for Pd
Jonathan Wilkes
jancsika at yahoo.com
Fri Nov 18 21:44:15 CET 2011
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Thomas Grill <gr at grrrr.org>; "pd-list at iem.at" <pd-list at iem.at>; Miller Puckette <msp at ucsd.edu>; IOhannes m zmoelnig <zmoelnig at iem.at>
> Sent: Friday, November 18, 2011 3:34 PM
> Subject: Re: [PD] "get" method for Pd
>
>
> On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
>
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>> To: Jonathan Wilkes <jancsika at yahoo.com>
>>> Cc: Thomas Grill <gr at grrrr.org>; "pd-list at iem.at"
> <pd-list at iem.at>; Miller Puckette <msp at ucsd.edu>; IOhannes m
> zmoelnig <zmoelnig at iem.at>
>>> Sent: Friday, November 18, 2011 1:33 PM
>>> Subject: Re: [PD] "get" method for Pd
>>>
>>>
>>> On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote:
>>>>> 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.
>>>
>>> I think having individual objects that are bangable is the best
> approach. Why
>>> don't you like it?
>>
>> Because if you want to get n data about pd (or from a canvas) you have
>> to have n objects. One of my biggest pains in Pd comes when I need to
>> map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.]
> connected
>> to however many message boxes, it's a lot of patching work to do
> something
>> very simple. So if I had a patch that needed many of your objects above,
>> it's a pain.
>
> I don't see how typing the message boxes for the send/receive approach is
> really much less typing and patching than the single object approach. And it
> does make the patch a lot more readable. As for your [route] example, that
> doesn't quite seem related. You can also do programmatic matching using
> [select], and other approaches.
>
>>> I'm just about done with a [canvasvisible] object for
>>> iemguts to illustrate this idea.
>>
>> I'm not wild about the interface of some of the iemguts objects-- one
> of them
>> differentiates between "list" and "bang" to trigger
> different behavior, and
>> the level for [sendcanvas] isn't settable.
>
> Yes the depth should be settable, that should be possible to add, not a lot of
> work. Which differentiates between list and bang?
canvasargs I think.
> That can make sense
> depending on the context.
Name another object in the history of Pd that (purposefully) does that.
-Jonathan
>
> .hc
>
>
>
>>
>> -Jonathan
>>
>>>
>>>> * 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.)
>>>
>>> Having individual objects means the most minimal and Pd-ish syntax:
>>>
>>> [bang(
>>> |
>>> [nogui]
>>> |
>>> [1(
>>>
>>>
>>>> * 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.
>>>
>>> You could combine [sendcanvas] and [receivecanvas] into [thiscanvas]
> with an
>>> inlet for the receive and an outlet for the send.
>>>
>>>> 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.
>>>
>>> I think we all agree on the end goal here. It sounds there are two
> things here:
>>> iemguts-like functionality for interacting with the patch's
> t_canvas
>>> (posonparent, parent, coords, etc.) and getting info from the global
> (nogui,
>>> version, rtflag, etc.). For things about interacting with the t_canvas
> that are
>>> missing from iemguts, I think they should be added to iemguts. Then
> for global
>>> things, we can start a new lib.
>>>
>>> .hc
>>>
>>>
>>>
> ----------------------------------------------------------------------------
>>>
>>> "Making boring techno music is really easy with modern tools, but
> with live
>>> coding, boring techno is much harder." - Chris McCormick
>>>
>
>
>
> ----------------------------------------------------------------------------
>
> If nature has made any one thing less susceptible than all others of exclusive
> property, it is the action of the thinking power called an idea, which an
> individual may exclusively possess as long as he keeps it to himself; but the
> moment it is divulged, it forces itself into the possession of everyone, and the
> receiver cannot dispossess himself of it. - Thomas Jefferson
>
More information about the Pd-list
mailing list