On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] "get" method for Pd
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?
Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain.
I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches.
I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.
I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between "list" and "bang" to trigger different behavior, and the level for [sendcanvas] isn't settable.
Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang? That can make sense depending on the context.
.hc
-Jonathan
- 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
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson