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
