On Nov 17, 2011, at 9:58 PM, Jonathan Wilkes wrote: > ----- 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 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 <[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. >> >> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
