Update to this: it seems that I can just use t_pd pointers to open and close the patches, although I still need to return the t_pd *x pointer from glob_evalfile().  I don't know which method is best for opening/closing, with t_canvas or t_pd..  

The new methods look like this:

t_pd *glob_evalfile(t_pd *ignore, t_symbol *name, t_symbol *dir)

{

    t_pd *x = 0;

    t_pd *x_loaded = 0;

/* even though binbuf_evalfile appears to take care of dspstate,

we have to do it again here, because canvas_startdsp() assumes

that all toplevel canvases are visible.  LATER check if this

is still necessary -- probably not. */

    int dspstate = canvas_suspend_dsp();

    binbuf_evalfile(name, dir);

    while ((x != s__X.s_thing) && (x = s__X.s_thing)) 

    {

vmess(x, gensym("pop"), "i", 1);

x_loaded = x;

    }

    pd_doloadbang();

    canvas_resume_dsp(dspstate);

    return x_loaded;

}

t_pd *libpd_openfile(const char *basename, const char *dirname) {

t_pd *x = glob_evalfile(0, gensym(basename), gensym(dirname));

pd_pushsym(x);

int dzero = canvas_getdollarzero();

pd_popsym(x);

return x;

}

void libpd_closefile(t_pd *x) {

pd_free(x);

}

I would appreciate any feedback/suggestions from you guys who know the pd API much, much more thoroughly that myself.

Cheers,

Rich

On Sun, Feb 6, 2011 at 4:49 PM, Rich E <reakinator@gmail.com> wrote:

I can't remember, are questions related to pd's C API appropriate for pd-list, or are they better asked here?  It seems that everyone who responds to those questions is on this list just as much, anyway.

I have been mucking around with opening and closing pd patches using API calls instead of pd's messaging system.  The reason for this is that I would like to be able to manage (open/close) multiple instances of a patch, and be able to send each copy of the patch a unique message via its $0 argument (see http://www.mail-archive.com/pd-list@iem.at/msg41648.html).  So far, the method has been to hack glob_evalfile to look like:

t_canvas *glob_evalfile(t_pd *ignore, t_symbol *name, t_symbol *dir)

{

    t_pd *x = 0;

/* even though binbuf_evalfile appears to take care of dspstate,

we have to do it again here, because canvas_startdsp() assumes

that all toplevel canvases are visible.  LATER check if this

is still necessary -- probably not. */

    t_canvas *x_canvas = 0; 

    int dspstate = canvas_suspend_dsp();

    binbuf_evalfile(name, dir);

while ((x != s__X.s_thing) && (x = s__X.s_thing)) 

{

x_canvas = canvas_getcurrent();

vmess(x, gensym("pop"), "i", 1);

}

    pd_doloadbang();

    canvas_resume_dsp(dspstate);

    return x_canvas;

}

The only addition is that x_canvas is retrieved before x is 'popped' off of pd's global stack, and is then returned, giving me a handle to close that particular patch with something like:

canvas_menuclose(x_canvas, 0);

But I realize that in global_evalfile, t_pd and x_canvas point to the same address space.  This leads me to ask, what is the difference between these two pointers?  Is t_canvas a t_pd along with variables for its graphical nature?

Mathieu also pointed to me (as I was using the first set of these) that canvas_setcurrent() and canvas_unsetcurrent() are aliases of pd_pushsym() and pd_popsym().  Is there a good reason to use one over the other?   

Last question:  Does anyone see a way that I could get the value of x in glob_evalfile above without changing the function?  I don't think it is a dangerous change (and it looks like I could just hand x.gl_pd to canvas_menuclose, thereby not really needing a t_canvas pointer), but I would of course prefer to not change the API if possible.

Cheers,
Rich

_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev