[PD-dev] info classes

Jonathan Wilkes jancsika at yahoo.com
Tue Mar 5 00:35:15 CET 2013


Ok, I've got some working code for building a simple linked list
of classes and a function to return a class by symbol.  This should
be fun.

Should I go ahead and make some convenience functions for
accessing class members?  That way anyone who wants to
use this functionality can get info on a class without worrying
about being locked in to the class struct if it happens to change.

-Jonathan




----- Original Message -----
> From: Jonathan Wilkes <jancsika at yahoo.com>
> To: Jonathan Wilkes <jancsika at yahoo.com>; "pd-dev at iem.at" <pd-dev at iem.at>
> Cc: 
> Sent: Saturday, March 2, 2013 3:45 PM
> Subject: Re: [PD-dev] info classes
> 
> ----- Original Message -----
> 
>>  From: Jonathan Wilkes <jancsika at yahoo.com>
>>  To: Jonathan Wilkes <jancsika at yahoo.com>; "pd-dev at iem.at" 
> <pd-dev at iem.at>
>>  Cc: 
>>  Sent: Friday, March 1, 2013 1:27 PM
>>  Subject: Re: [PD-dev] info classes
>> 
>>  Just made a change so that the "args" method grabs from
>>  the parent instead of the root canvas.
> 
> After some more testing I think this change is wrong. If [my_abstraction]'s
> args are "foo bar" and I'm inside subpatch [pd blah], the tk 
> window for [pd blah]
> shows the args as "(foo bar)" and not "(blah)".  But this is 
> just an effect
> of the larger point, which is that the _abstraction_ arguments are the ones
> that replace dollarsign variables regardless of which subpatch you happen to
> be in.  So the "args" method to [canvasinfo] should return the atoms 
> that will
> replace $1, $2, $3, etc. in the context of the current canvas.  Even for nested
> subpatches, that means the arguments for the root canvas (i.e., containing
> abstraction, or if there's no abstraction then the toplevel patch), so those 
> are
> the ones that will be returned.  That makes the canvasinfo "args" 
> method
> consistent with the rest of the Pd interface.
> 
> The only question is how to accommodate a user who wants to grab the args
> of a [pd].  For this I'd like to simply add a method that returns the entire 
> object
> box contents for the current canvas.  So [pd blah] would return "pd 
> blah",
> [foo-abstraction 1 2 3] would return "foo-abstraction 1 2 3", and so 
> on.  (I suppose
> a toplevel patch would just return a bang since there's no box, and I 
> already
> have a "filename" method.)
> 
> But what should I call the method?  objstring? boxmatter? boxtext? boxguts?
> 
> -Jonathan
> 



More information about the Pd-dev mailing list