[PD] "get" method for Pd
Jonathan Wilkes
jancsika at yahoo.com
Fri Nov 18 03:58:29 CET 2011
----- 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.
>
More information about the Pd-list
mailing list