[PD] "get" method for Pd

[Hans-Christoph Steiner]

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?  That can make sense depending on the context.

.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