[PD] "get" method for Pd
jancsika at yahoo.com
Fri Nov 18 20:58:36 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 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
>>> 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
>> 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
>> 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.
>> 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'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.
>> * 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:
>> * 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.
> "Making boring techno music is really easy with modern tools, but with live
> coding, boring techno is much harder." - Chris McCormick
More information about the Pd-list