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 billy.stiltner@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at 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 jancsika@yahoo.com 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=557...

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.

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

From: Billy Stiltner billy.stiltner@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, March 7, 2012 12:19 AM Subject: Re: [PD] nonlocal message passing scope

I don't know if making it easier to do would be good for learning but it sure would be easier for doing. haha!

Well, if you had abstraction wrappers for [s]/[r], [throw~]/[catch~], [s~]/[r~], [v], and dialog box entries for the

"Put" menu array and iemguis (and possibly canvas properties), you wouldn't have to bother with $0 as a user.

Plus a convenience abstraction to prefix a given symbol based on the scope you want, so that you can use it

as a send-symbol inside message boxes.  I guess the sticking points are objects that take an array name as

an argument-- in the majority of cases those are settable, so I guess the user could choose between

loadbanging a symbol or just using $0-prefixes there.

There are probably other uses of $0 that I'm missing... [struct] names I guess, but there you're already

punished for using $0 since it makes it impossible to reload scalar state.

-Jonathan

I try not to think about how that works. once I figured it out I wrote down what I learned and use it as a reference or I'll just go look in  a patch that I have used in and duplicate.

I got stuck redoing an lfo for polysynth where each voice has it's own lfo osces but the tables sit in a parent patch. Its easy to name the lfo tables $0lfo1 ,$0lfo2 . It is not so simple when putting the table in an abstraction that can be reused. I guess just name the table $2$1 and pass in the creation argument lfo1 $0. For some reason though other things got confusing inside the abstraction.

I hadn't ever seen that before. not sure what it does Ill have to try it out. The table does have to be unique to the main patch but used from several sub patches. Thanks for making me think about how to keep the main patch abstractable. I guess that calls for tacking on the lfo canvases $0 to the front of the table name then sending the tables name out upon creation and sending it to each of the tabosc~ in each voice. like gimme for the table name.

In my demo I addressed canvas levels, but it should be easy to add some stuff for abstraction levels, too.

If a singleton table is what you're after, here's an extremely ugly hack:

[loadbang] | | [r once] | / [v table_exists] | [sel 0] | [obj 20 20 table singleton, obj 20 70 v table_exists; once 1( | [s pd-_float]

-Jonathan

...