[PD] Internal pd problems...or features ?

Miller Puckette mpuckett at man104-1.ucsd.edu
Wed Jan 23 20:16:33 CET 2002

By coincidence I just hit the same problem (a) last night.  I wonder
if I had some reason for doing it that way...?  Anyway, I've tried putting
the calls in the more natural order, in text_setto() (g_text.c):

	    	/* normally, we just destroy the old one and make a new one. */
    	    glist_delete(glist, &x->te_g);
    	    canvas_objtext(glist, x->te_xpix, x->te_ypix, 0, b);
	    	/* if it's an abstraction loadbang it here */
	    if (newest && pd_class(newest) == canvas_class)
    	    	canvas_loadbang((t_canvas *)newest);

So far it seems fine.

as to (b) I don't know what's wrong; sounds like something's getting
overwritten somewhere.  Anywhere (after the t_pd header) in your object
struct you can put items which are themselves "structs".  You can also put
pointers; just make sure you have something to point to of course...


On Wed, Jan 23, 2002 at 04:51:26PM +0100, Yves Degoyon wrote:
> sorry to bother you again, Miller,
> but i've found the following features 
> annoying in PD 0.35-TEST4 :
> a/ when, in the gui, you change parameters
> to an objet, a new object is created 
> and the former one destroyed, ok.
> BUT, the order of calls is the following :
> new replacement
> free old
> that's annoying 'cause you can't handle
> an instances counter properly. 
> i'd rather have :
> free old
> new replacement
> b/ i don't know why but i tried to add a structure
> to my object and, all the sudden, it became 
> "not patchable" and couldn't be created.
> what does this mean ??
> the structure added is a MPSTR structure from lame.
> what's wrong with doing this ???
> that's all for critics,
> i still enjoy PD everyday
> but there are some tricks in external development.
> don't bother, i don't know of a software which
> doesn't have any.
> cheers,
> Yves/
> Next in Thread ----> NULL

More information about the Pd-list mailing list