"On 6/17/21 23:47, Miller Puckette via Pd-list wrote:
to scare people... more seriously, because I'd consider such a thing "meta" (such as message back-tracing, which I also want to add someday)
i see.
I don't have a precise idea what I mean by "meta" here.
:-)
afaict, there's a couple of different object-types:
- "normal", modular-synth like objects
this probably includes practically *all* signal-processing objects (e.g. [osc~]) and other, simple operator objects (e.g. [+])
- "language"-defining constructs.
this is the class of objects that define the "patcher language". i think there are at least two subgroups a. data-flow objects ([trigger], [spigot], [select], [route], [until],...) b. abstract concepts, such as subpatches ([pd]), abtractions, arguments ($1), declarative objects ([declare], [namecanvas], [block~]/[switch~],...), but also [clone] and [pd~]
- "introspection" thingies
objects that allow us to gather meta-information on the patch itself. iemguts is an external collection of mostly such objects. but there's also built-in support for introspection, e.g. the [dir( and [isvisible( messages to [pdcontrol].
for me, "meta"-objects would be of the 3rd kind (and probably 2b).
i think that error-reporting - as we know it from other languages like C++, java, python,... - is a typical "language" feature. otoh, getting a backtrace is more about introspection of the running patch.
i understand that you are reluctant to add new "language" (or even "instrospection") features, as it's practically a bottomless pit (and where would we end up, if we stared too long into that? ;-))
now what i really hate about [pdcontrol], is that it belongs to all three categories. of course the groups are not totally orthogonal, and there's certainly object that fit into more than one (e.g. [change]).
but with [pdcontrol] this is different, as it just bundles unrelated functionality into a single object, but the so-far implemented functionalities actually are rather easy to categorize:
- [browse(->[pdcontrol] just belongs to the "normal" group (it is
somehow non-standard as it is asynchronous and involves the Pd-GUI, but that is actually an implementation detail)
- [args( is really just an extension of the argument-system (and it was
always possible to get all arguments of a patch; it just involved a lot of idiosyncracies (which is ok, as we are on the "language"-level) and the only way to re-use the code was by copy-and-paste (instead of wrapping it into an abstraction)
- as mentioned above, [dir( and [isvisible( messages really give you
meta-information about the patch, so they belong the "introspection" group.
and of course the name "pdcontrol" does not suggest *any* of the functionality we have so far. leaving out the [browse( message (which could just be implemented in a dedicated object and no-one would be off any worse), all the other messages so far operate on either a canvas- or a patch-level. at least for me, "pdcontrol" always suggests an "interface to control/communicate with Pd" (very much related to what we can already do by sending things to "pd"; but - being an object - theoretically much more powerful, as it allows us to get data back). i definitely don't read that name as "interface to a [pd]". it also doesn't convey the meaning of "this is a perilous realm; go away and be scared".
and then there is [pdcontrol catch-printout] which is actually a totally different objectclass. hmm.
for practical reasons, i think it might help if we could just separate the various functionalities into separate objectclasses. at least like [pdcontrol args] and [pdcontrol dir]. i guess nobody actually has a need to query the selfsame object for both the visibility state of a window and to ask it where on the disk supplementary files are located. probably also rename the object to [canvascontrol] or [patchcontrol].
in order to scare people away from using experimental objects, we might use some prefix clearly marking them as such: [XXX.browsefile]
and finally: which object would I use to get the version of the running Pd?
mfgds IOhannes