<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>There's also the (currently) underutilized "send-window" method of [pointer], which forwards a message to the canvas of the scalar that [pointer] is currently pointing at. Additionally, you can use the "traverse" method to point to the head of a glist (which doesn't even need to contain a scalar) and forward messages that way.</span></div><div><br><span></span></div><div><span>If you look at the canvas "get" method I added to the tracker, you'll see I have a "get parent RECEIVE-SYMBOL" message that returns a pointer to the parent canvas (or a zero if there isn't one). This allows you to:</span></div><div><br></div><div>[bng]</div><div>|</div><div>[f $0]<br></div><div>|<br><span></span></div><div><span>[get parent $1-rcv]</span></div><div><span>|</span></div><div><span>[s
pd-$0-mysubpatch]</span></div><div><br><span></span></div><div><span>[r $0-rcv]</span></div><div><span>|</span></div><div><span>[route parent]</span></div><div><span>|</span></div><div><span>[route 0]</span></div><div><span> |<br></span></div><div><span>[pointer]<br></span></div><div><br></div><div>Now [pointer] is pointing at the parent of [pd $0-mysubpatch], so if I immediately follow this by sending the message "send-window obj 20 20 clip" to [pointer], I get a [clip] object on it's parent. That's just a silly example, but notice it's different than sending to pd-PATCH-FILENAME.pd, which would draw a [clip] on every instance of that patch that is open.<br></div><div><br></div><div>Put this in an abstraction and it obsoletes [namecanvas]. Or create an abstraction to climb to the root, or the toplevel, etc.</div><div><br></div><div>-Jonathan<br></div><div><br><blockquote style="border-left: 2px
solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><font face="Arial" size="2"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Frank Barknecht <fbar@footils.org><br><b><span style="font-weight: bold;">To:</span></b> pd-list@iem.at<br><b><span style="font-weight: bold;">Sent:</span></b> Tuesday, August 2, 2011 4:14 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [PD] [PD-announce] Pd Convention - Data structures workshop: Taking your requests<br></font><br>On Mon, Aug 01, 2011 at 08:59:49AM -0500, Charles Henry wrote:<br>> I'm mainly interested in using Pd for scientific and engineering<br>> research. I have a mixed level of experience--I'm deep into the DSP<br>> routines, but I have no clue how data structures
work.<br>> <br>> About the only application I can think of right now is a "data<br>> logger"--recording info about a particular trial/experiment and its<br>> results.<br>> <br>> I'd like to learn easy or more compact ways to accomplish things with<br>> data structures.<br>> <br>> I will look forward to your workshop! Thanks much!<br><br>Data structures can be nice problem solvers in unexpected areas as well,<br>not only in visualizing/graphically editing data. For example, they are<br>used hidden away to implement a fast vanilla list sorting in the newest<br>[list-sort], or in the [m_symbolarray] object of the rj library to<br>mimick a [table] object that stores indexed symbols instead of floats. <br>A users of these objects never sees the data structures inside, <br>they don't even have a graphical representation but instead are just<br>used as what their name says: as data structures.<br><br>Ciao<br>--
<br>Frank<br><br>_______________________________________________<br><a ymailto="mailto:Pd-list@iem.at" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br><br><br></div></div></blockquote></div></div></body></html>