[PD] Ability to access error messages from patch
IOhannes m zmölnig
zmoelnig at iem.at
Fri Jun 18 13:57:07 CEST 2021
"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 don't have a precise idea what I mean by "meta" here.
afaict, there's a couple of different object-types:
1. "normal", modular-synth like objects
this probably includes practically *all* signal-processing objects (e.g.
and other, simple operator objects (e.g. [+])
2. "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~]
3. "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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the Pd-list