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 Fri, Jan 25, 2013 at 9:27 PM, Jonathan Wilkes <[email protected]> wrote: > > > > > ----- Original Message ----- >> From: Bill Gribble <[email protected]> >> To: Jonathan Wilkes <[email protected]> >> Cc: Lorenzo Sutton <[email protected]>; "[email protected]" >> <[email protected]> >> Sent: Friday, January 25, 2013 7:55 PM >> Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released >> >> On Fri, 2013-01-25 at 15:21 -0800, Jonathan Wilkes wrote: >>> > From: Bill Gribble <[email protected]> >>> > I am working on a pd-clone intended to explore a lot of the topics in >> this >>> > thread. It's not fully baked yet -- the biggest working patch is >> a biquad >>> > filter designer with pole-zero and freq response plotting -- but >> I'm >>> > particularly excited about the approach to namespacing and scope >> management, >>> > which works a lot like hc describes. Patches have a set of scopes >> which can be >>> > mapped onto subpatches (represented as layers, not separate windows). >> Name >>> > resolution in send/receive elements works like you would want it to. >>> >>> How does scope work for abstractions? >> >> Well, every object in a patch has a name. To find that object, the tree >> of patches and scopes is crawled upward from the site of the lookup. For >> example, the (equivalent of) [s "foo"] first looks in the scope of the >> [s], then the patch-global scope of the containing patch, then in the >> application global scope for the name "foo". >> >> Dotted notation can drill down, so [s "foo.bar"] would try to find an >> object named "foo", then find "bar" in its patch-global >> scope (or an >> object named "bar" within a scope named "foo" in the current >> patch). >> >> Does that make sense? > > I don't think I understand it. > > Let's say I have abstraction [blah]. I want [s foo] and [r foo] inside > [blah] and > all of [blah]'s children to talk to each other. Then I want to share my > abstraction > with Bob who needn't worry about the send/receive names I used inside [blah] > because they are guaranteed not to conflict with anything he does outside the > scope of the [blah] abstraction (e.g., creating a [s foo] on the same canvas > where > a [blah] object sits). > > Can I specify the scope of the s/r symbol in this way? > > Jonathan > >> >> Thanks, >> Bill Gribble >> > > _______________________________________________ > [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
