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 jancsika@yahoo.com wrote:
----- Original Message -----
From: Bill Gribble grib@billgribble.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Lorenzo Sutton lorenzofsutton@gmail.com; "pd-list@iem.at" pd-list@iem.at 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 grib@billgribble.com 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list