[PD] "get" method for Pd

[Hans-Christoph Steiner]

On Nov 17, 2011, at 9:58 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 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.

No matter what the format of the list itself, having to set all of the possibilities at once makes it very hard to work with.


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

You think that ~2300 words is not particularly large for a help file?  That's now long Tcl's info help is.  I don't think any Pd help patch has anywhere close to 2300 words.

.hc


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

News is what people want to keep hidden and everything else is publicity.          - Bill Moyers