That makes sense, all except the names. :) Nice docs. On Tue, Feb 8, 2011 at 6:33 AM, Hans-Christoph Steiner <[email protected]>wrote:
> > t_canvas is now just a t_glist. a t_glist is a list of objects that > represents a patch, here's what I wrote about it a while back: > > http://wiki.puredata.info/en/glist > > I am pretty sure that t_pd is a generic class pointer, like a pointer to > Object in Java. > > .hc > > On Feb 6, 2011, at 2:15 AM, Rich E wrote: > > 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 <[email protected]> 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/[email protected]/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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev > > > > > > ---------------------------------------------------------------------------- > > The arc of history bends towards justice. - Dr. Martin Luther King, Jr. > > >
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
