[PD-dev] difference between t_canvas and t_pd

[Hans-Christoph Steiner]

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



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

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/4902ea13/attachment-0001.htm>