[PD] "get" method for Pd

[Hans-Christoph Steiner]

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? I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.

> * 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