[PD] "get" method for Pd
Hans-Christoph Steiner
hans at at.or.at
Fri Nov 18 04:24:58 CET 2011
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
More information about the Pd-list
mailing list