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 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

----------------------------------------------------------------------------

The arc of history bends towards justice. - Dr. Martin Luther King, Jr.

Thanks. Please add there as you figure out stuff, don't worry about getting it exactly right, its a wiki, so it can be changed :)

.hc

On Feb 8, 2011, at 4:47 AM, Rich E wrote:

That makes sense, all except the names. :) Nice docs.

On Tue, Feb 8, 2011 at 6:33 AM, Hans-Christoph Steiner hans@at.or.at 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 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

---

The arc of history bends towards justice. - Dr. Martin Luther King, Jr.

----------------------------------------------------------------------------

Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom

On Tue, Feb 8, 2011 at 6:34 AM, Hans-Christoph Steiner hans@at.or.atwrote:

I forgot to add, if you want to read a file to load a patch, my guess is that you'll want to return a t_glist.

Hm, I actually didn't even think I could write my own function for evaluating a patch until you mentioned this, but now I see that everything glob_evalfile is doing is also publicly available, and there is no need to hamper with it (unless others think that it _should_ return its t_pd *x). So.. sweet! I got a nice objective C class going that manages multiple copies of the same patch, and can talk to each one in private.. will talk more about that on the Pd Everywhere (libpd) mailing list.

Cheers, Rich

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 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

---

Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.

• retired U.S. Army general, William Odom