On Fri, Jan 4, 2013 at 11:36 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: IOhannes zmölnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Friday, January 4, 2013 4:43 AM Subject: Re: [PD-dev] from t_symbol to t_class
On 01/04/2013 07:19 AM, Miller Puckette wrote:
I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the "return value"
(the
global "newest" is zero. If not it's a proper Pd object you
can use zgetfn()
on to test it for messages.
Main problem I see with this is that some classes like "select"
and "list"
are actually several classes that share a name (and which one gets
created
depends on the arguments sent to vmess())
also, what happens if the object in question accesses some hardware
ressource?
e.g. [pix_video] will try to grab an available video-source, potentially
locking
a hardware device. in theory this should not be aproblem, as the object will hopefully be
freed by
[classinfo] asap, but in practice it might have all kinds of
side-effects,
starting from short lockups of Pd to launching rockets.
I'd prefer to just inspect the class without creating a new instance but I can't figure out how.
Are all t_gobj linked together in one big list?
-Jonathan
I think the t_gobj are in a list per canvas--see the canvas_dodsp method in g_canvas.c to see how it's done.
Classes in Pd exist without having an instance of the class. Once the setup method is called (which for externals will require you to create an instance), the class data structure is created and loaded with all its methods. However, I don't know how to get a pointer to the class, when all you know is the symbol.
Within a class, the methods are stored in an array "c_methods". See the class definition in m_imp.h. You can dump out all the symbols that have methods by looping over the array from 0 to (c_nmethod-1) and accessing the method's "me_name".
Chuck