[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: Miller Puckette <msp at ucsd.edu>; "pd-list at iem.at" <pd-list at iem.at>; IOhannes m zmoelnig <zmoelnig at iem.at>
> Sent: Thursday, November 17, 2011 5:50 PM
> Subject: Re: [PD] "get" method for Pd
> 
> 
> On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote:
> 
>>  ----- Original Message -----
>> 
>>>  From: Miller Puckette <msp at ucsd.edu>
>>>  To: Hans-Christoph Steiner <hans at at.or.at>
>>>  Cc: pd-list at iem.at; IOhannes m zmoelnig <zmoelnig at iem.at>
>>>  Sent: Thursday, November 17, 2011 1:42 PM
>>>  Subject: Re: [PD] "get" method for Pd
>>> 
>>>  T his leads to an interesting larger design issue.  I've so far 
> resisted
>>>  the idea of using send/receive as a back channel for getting return
>>>  values because of the unreadablity of the resulting patch.
>> 
>>  I was thinking: from that same vantage point, the core list classes 
>>  do a terrible job of processing lists.  The resulting pd code for 
> sorting/splitting/etc.-- 
>>  stuff that is elementary in many other programming languages-- 
>>  either ends up being simplistic and inefficient, or efficient but
>>  extremely weird and difficult to read (just have a look at the innards of 
>>  [listabs/list-drip] for example).  Yet it's better to have the core 
>>  list classes plus a library of abstractions-- listabs-- that hides the 
> ugliness 
>>  necessary to get decent list processing to happen in Pd, than to not have 
>>  the list classes at all.
>> 
>>  Similarly, object chains with a big blank space between a [send] and its 
>>  corresponding [receive] aren't great, but if they can provide access to 
> desired data 
>>  about a pd instance, canvas instance, array, scalar-- i.e., things that 
> don't have 
>>  an inlet to hook into-- then we can build an abstraction around that to 
> provide a 
>>  unified interface for the user.
> 
> It sounds to me that this is unifying too many things.

It will never be the case in Pd that something-- anything-- is too unified.

> I think all this stuff 
> should be gettable using the same style and technique (i.e. messages, inlets, 
> outlets, etc)  but not necessarily in the same object.  The mediasettings lib 
> provides a way to get and set the audio/midi settings, the iemguts library 
> provides a means for getting and setting info about the patch and canvas.
> 
> As long as all this libs and objects use the same idioms for interaction, then I 
> think this is a much preferrable route than having a single centralized [info] 
> object with hundreds of messages.

Yeah, it's overkill to wrap _everything_ into one object, but for the things that I 
listed which don't have an inlet, a unified object would be nice.  Maybe choosing 
context by the inbound message type like I described would be problematic-- 
so maybe an approach similar to the list classes where the arg sets the class 
to be used.

> 
> One example of such an idiom is having a data outlet and a status outlet, like 
> comport, hid, etc.  Another example is the [textfile] way that you can go thru a 
> list of things: load it, bang it get the next element, catch bang from 
> right-outlet  when the list is done.

Is there a way to standardize a "get" method?  I mean, if some externals took 
float messages, and others took "float NUMBER PRECISION" messages, and 
yet another took "float32 NUMBER", I wouldn't use Pd.  So when you imply that 
the solution is all these disparate libraries that pretty much do what people 
need, and all in their own disparate ways, I'm leery.

-Jonathan

> 
> .hc
> 
> 
> 
> ----------------------------------------------------------------------------
> 
> I hate it when they say, "He gave his life for his country."  Nobody 
> gives their life for anything.  We steal the lives of these kids.  -Admiral Gene 
> LeRocque
>