[PD] "get" method for Pd

[Hans-Christoph Steiner]

On Nov 18, 2011, at 3:44 PM, Jonathan Wilkes wrote:

>> On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
>>>> 
>>>> 
>>>> 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.


I don't really see what you mean in canvasargs.  [+] behaves differently when given a bang or a list.  Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result.

.hc





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




----------------------------------------------------------------------------

All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne