[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 9:17 PM
> Subject: Re: [PD] "get" method for Pd
> 
> 
> On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote:
> 
>> 
>> 
>> 
>> 
>>  ----- 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.
> 
> The audio dialog message and the midi dialog message are too unified.  Things 
> like sample rate, channels, etc. should be settable individually.

Oh, you mean all mashed together in a big nondescript list?  Here again it's too bad
that lists don't nest in Pd-- that way you could just get one list of many key/values.

> 
> 
>>>  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.
> 
> The last sentence is the key there.  They should not all do these things in 
> their own disparate ways.  If the objects stick to common, well-established 
> idioms, then all these objects will be easy use.  Just imagine the help patch of 
> an [info] object with so many messages vs the help patch for each object and its 
> specific task.

But all the messages would follow the same syntax.  Take [info] in tcl-- it doesn't have 
a particularly large help file.

-Jonathan

> 
> .hc
> 
> 
> ----------------------------------------------------------------------------
> 
> The arc of history bends towards justice.     - Dr. Martin Luther King, Jr.
>