[PD] "get" method for Pd

[Hans-Christoph Steiner]

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

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.

.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