[PD] "get" method for Pd

[Jonathan Wilkes]

----- 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'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.

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