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