On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@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@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@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.