----- Original Message -----
From: Billy Stiltner billy.stiltner@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Bill Gribble grib@billgribble.com; "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 9:43 PM Subject: Re: [PD] GUI toolkits and custom GUIs WAS: Integra Live 1.5 released
Here's how I've managed to send and receive from a parent(multi instance) abstraction to multiple instances of nested sub abstractions.
I'm talking about doing it without the constraint of having to prepare the child abstractions beforehand with an argument that contains a dollarsign variable. Passing unique identifiers around to simulate scope is really painful. In fact I was going to write some trivial tcl example code here to show how clunky the $0 approach would be, but I can't even imagine what it would look like.
-Jonathan
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 ->