I think the one thing I didn't cover that you mentioned was a parent trying
to send data toan individual child abstraction. Even if you could step through the entire glist one canvas symbol at a time, it's still extremely clunky and would require using the canvas "echo" method to pass messages which as matju mentioned would confuse the abstraction's canvas with the abstraction itself. Plus if you have multiple abstractions it's not possible to tell them apart, aside from unique arguments, so as far as I can tell this is something that has to be done manually as you outline below. For everything else, though, there is no reason to be explicitly passing the dollarsign zero as an argument-- which quickly gets ugly and unwieldy in a complex patch-- _if_ Pd provides a way for the user to query canvas attributes (like $0) all the way up to the toplevel. That's what my canvas "get" method does, and that's why I'm suggesting some abstractions to ease defining the scope for nonlocal message passing. -Jonathan >________________________________ > From: Billy Stiltner <[email protected]> >To: Jonathan Wilkes <[email protected]> >Cc: "[email protected]" <[email protected]> >Sent: Tuesday, March 6, 2012 7:30 PM >Subject: Re: [PD] nonlocal message passing scope > > >Here's how I've managed to send and receive from a parent(multi instance) abstraction to multiple instances of nested sub abstractions. > >within main abstraction [mainAb] >some data named $0var send it like this [s $0var] > >initialize sub abstractions >pass names X_1 and X_2 in so you can send and receive data to these >abstractions individually >[abX X_1 $0] [abX X_2 $0] > >within sub abstraction abX initialized with X_1 >$1 = X_1 >$2 = mainAb's $0 > >for all instances of abX >to receive from main's [s $0var] >[r $2var] > >to to send and receive locally and have mainAb access >within abX [s $2$1varZ] >within mainAb [r $0X_1varZ] and [r $0X_2varZ] > >a way to get global data to sub abstractions of abX >within abX initialize [abY $2var] >within abY $1var = mainAb $0var > >This information is useful say if you have multiple voices and want to have >them share the same control > >so say $0var is a send on a filter frequency slider >when you move the slider all instances of abX receive the new filter frequency > >when you want information to or from a specific instance of abX say like you >want to plot each of the voices outputs on a scope >use [s~ $2$1varZ] in abX >then in main [r~ $0X_1varZ] and [r $0X_2varZ] then you can write those to a >table so you can see which voice is sounding >________________________________ > > > >On Tue, Mar 6, 2012 at 5:29 PM, Jonathan Wilkes <[email protected]> wrote: > >Hello, >> I was thinking about scope for receive/send names yesterday and >> >>thought of a way to implement something more flexible than >> >>(explicitly) using $0 to define the scope of send/receive pairs (and >> >>possibly other objects that register a symbol). >> >>My hack makes use of my "get" method for canvases patch: >>http://sourceforge.net/tracker/?func=detail&aid=3308027&group_id=55736&atid=478072 >> >>Right now I'm seeing several categories, and I'm not sure how they all >>relate-- >> >>meaning they may or may not require different approaches: >>1) _this_ canvas, basically what you would get if you prefixed the >> >>.x12345 name before the s/r symbol >> >>2) ways to break out of a canvas environment to the parent, parent of parent, >>etc., >> >>all the way to toplevel >>3) ways to communicate among abstraction instances, including >> >>_this_ abstraction, all abstractions on the parent, parent of parent, etc., >>to toplevel >> >>4) ways to communicate among all libdir abstractions* >> >>5) global s/r names, abstraction global s/r names >> >>#1 is pretty simple-- just add an attribute for the canvas symbol to the >>"get" method, >> >>and prefix it to the s/r symbol. >>#2 is pretty simple, too-- just use integers to specify how far up the tree >>you want to >> >>go, get the $0 for that canvas environment, and prefix it to the s/r symbol. >>#3 is similar to #2, except that you also prefix the directory and filename >>with the $0 >>#4 is like #3 except that you leave out the filename >>#5 global is nothing prefixed, abstraction global is the directory and >>filename with no $0 >> >>I've made some abstractions [to] and [from] that can do the job for #1, 2, >>and global. >>($1 for level, $2 for the s/r symbol-- though I'm not sure if that's the best >>order) >> >>The question is do I also try to add the functionality for #3, 4, and >>abstraction global >> >>in those same objects, or do I make a [toabs]/[fromabs] pair for that purpose? >> >>In a way it'd be nice if there were a standard way to address all the >>possibilities above >> >>using only argument-- that way it'd be easy to add this functionality to >>already existing >> >>objects, like the array dialog and iemguis, with a single combobox (and >>simply default >> >>to whatever corresponds to global). The problem is that in both #2 and #3 a >>single float >> >>arg would be nice to specify the level so I'm not sure how to differentiate >>between the >> >>two. >> >>Also, are there any other contexts I haven't addressed in 1-5? >> >> >>-Jonathan >> >>* the only current example of this I can think of is inside the pddp libdir, >>where there's a >> >>global [v GLOBAL_PDDP_DSP] for the dsp status, but I'm not sure if it's used >>by anything >> >>other than ezoutput~.pd. >> >> >>_______________________________________________ >>[email protected] mailing list >>UNSUBSCRIBE and account-management -> >>http://lists.puredata.info/listinfo/pd-list >> > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
