[PD-dev] difference between t_canvas and t_pd

Rich E reakinator at gmail.com
Tue Feb 8 12:08:33 CET 2011


On Tue, Feb 8, 2011 at 6:34 AM, Hans-Christoph Steiner <hans at at.or.at>wrote:

>
> 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 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
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110208/cf58b568/attachment.htm>


More information about the Pd-dev mailing list