----- Original Message -----
> From: Hans-Christoph Steiner <[email protected]>
> To: Jonathan Wilkes <[email protected]>
> Cc: Miller Puckette <[email protected]>; "[email protected]" <[email protected]>;
> IOhannes m zmoelnig <[email protected]>
> 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 <[email protected]>
>>> To: Hans-Christoph Steiner <[email protected]>
>>> Cc: [email protected]; IOhannes m zmoelnig <[email protected]>
>>> 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.
> 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.
-Jonathan
>
> .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
>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
