[PD-dev] difference between t_canvas and t_pd
Rich E
reakinator at gmail.com
Tue Feb 8 10:47:59 CET 2011
That makes sense, all except the names. :) Nice docs.
On Tue, Feb 8, 2011 at 6:33 AM, Hans-Christoph Steiner <hans at 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 at 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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110208/910f803a/attachment.htm>
More information about the Pd-dev
mailing list