Just made a change so that the "args" method grabs from the parent instead of the root canvas. I initially didn't see a use case for grabbing the args of a [pd] object, but someone posted one awhile back.
Should I go ahead and also add a "selector" method to grab the selector of the parent canvas? This would make it possible to grab the "pd" selector or the name of the abstraction without the extension (e.g., ".pd"). This would be in addition to a "filename" method that grabs the gl_name regardless of whether you're in a [pd] or not. I find that necessary because, after all, we could be inside an abstraction within a max patch and so the patch author can't just append ".pd" to the "selector".
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: "pd-dev@iem.at" pd-dev@iem.at Cc: Sent: Thursday, November 15, 2012 2:34 AM Subject: [PD-dev] info classes
Here is a quick snapshot of a bundle of classes I'm working on to provide a standardized way to get properties from parts of pd that aren't "objectified":
[canvasinfo] get the properties of a canvas [pdinfo] get info about the running Pd instance [classinfo] info on a class (still under construction)
I currently have them below [print] in x_interface.c from 0.43, so you can just drop it in and compile with Pd Vanilla if you want to check it out. (I'll make a patch later.)
The props for [canvasinfo] are from my patch on the tracker that adds a "get" method to canvas. The nice thing about this particular
interface is that there is only one class per domain which makes it much easier IMO to learn and remember the tools you need to inspect data (vs the one class per property approach which I find cumbersome). For example, a bang to canvasinfo or pdinfo will print out a complete sequence of all properties and their values to the Pd window, so one doesn't even have to memorize the methods in order to see the values. Incoming messages are done "pack" style, so that "symbol method" and "method" work the same, and with [canvasinfo] "A_SYMBOL A_FLOAT" messages get distributed among the inlets as lists do.
I only have "dsp" and "version" properties for [pdinfo] so far. I'm curious what else would be useful.
[classinfo] just tells whether the incoming symbol is one that will create an object that is already loaded. I'm not sure what an incoming bang would do here, or what more information would be useful. Actually I think [declare -lib blah] fails silently, so you could use this as a way to "catch" missing objects and specify an alternative.
I stole some code from IOhannes to get canvas args without digging into the innards of g_canvas.c. :)
-Jonathan
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev