[PD] "get" method for Pd

Hans-Christoph Steiner hans at at.or.at
Fri Nov 18 03:17:49 CET 2011


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.


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

.hc


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

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





More information about the Pd-list mailing list