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