On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote: >> This is more like iemguts: properties of abstractions. Jonathan's proposal >> includes that, but also global things. IMHO, iemguts is the most Pd-ish >> because >> its a library of simple objects rather than a single absattr mega-object >> with >> attributes (Max/MSP style) or messages via send/receive. > > The max [pattrhub] object isn't what I'm after. I used [absattr] for the > @key value > syntax when it was sitting in a previous version of pd extended but that's > all. > > What I'm really after are some simple, core features that allow the user to > access simple, core data about the pd instance and canvas instance(s). > > For the pd instance the most obvious starting point is the version-- the > simplest > way is what I proposed about sending a query to the pd and > getting a response with a [receive pd]. Miller wants to avoid this approach > for readability reasons, so if there's a better approach I'd be interested in > hearing it. At the least it should have these features: > > * ability to return all data with a single bang/get/whatever message. > One-object-per-datum > like [version], [rtflag], [nogui], etc. isn't optimal.
I think having individual objects that are bangable is the best approach. Why don't you like it? I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea. > * clear syntax that can be extended to other areas of pd. I like the "get > $something" syntax > because one could also use it for getting data from the inlet of an object > and outputting it > to a subsidiary outlet. (Other selectors could be used-- that's just my > example.) Having individual objects means the most minimal and Pd-ish syntax: [bang( | [nogui] | [1( > * for canvases, the user must be able to make a distinction between "this > local canvas" and > "all canvases that have this receive symbol". (This is why [namecanvas] > isn't obsoleted by > sending to an abstraction's filename prefixed with "pd-".) The only ways > I've seen to do this > are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with > the send-window > method of [pointer]. Using either to query/receive canvas attributes will be > wireless, which > evidently isn't what Miller wants. You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send. > My idea is to have the pd community build abstractions around whatever way > these features > get implemented. Even if one method of getting the core functionality isn't > the most readable, > it can be wrapped in an abstraction that has an inlet and an outlet to make > it more readable. > If changes to the core functionality need to be made at a later date then the > innards of the > abstraction can be modified to fit those revisions without the abstraction's > interface being > affected. This way you open up development of these interfaces to the entire > Pd userbase, > rather than just people who can code in c. I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts. Then for global things, we can start a new lib. .hc ---------------------------------------------------------------------------- "Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
