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