On Nov 18, 2011, at 3:44 PM, Jonathan Wilkes wrote:
On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
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?
canvasargs I think.
That can make sense depending on the context.
Name another object in the history of Pd that (purposefully) does that.
I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result.
.hc
-Jonathan
.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
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne