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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
