Gary Lee Nelson

I want to create local (private) connections between a parent patch and its

subpatches. Is there a method whereby send and receive objects can be

privatized to a patch and its subpatches as does pv?

I know about #0 but that is not doing the job.

I want to create local (private) connections between a parent patch and its
subpatches. Is there a method whereby send and receive objects can be
privatized to a patch and its subpatches as does pv?

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

private-send-receive

Im assuming it has to be dynamic, otherwise inlets/outlets would be 

the obvious choice. Scripting the creation of inlets and outlets and 

Im guessing that you dont want to use send/receive because more than 

one sub patcher will also get the message, or you want to send to a 

group of subpatchers at the same time, but not at once?

On Sep 18, 2006, at 11:13 AM, Gary Lee Nelson wrote:

> I want to create local (private) connections between a parent patch 

> subpatches. Is there a method whereby send and receive objects can be

> privatized to a patch and its subpatches as does pv?

> I know about #0 but that is not doing the job.

Im assuming it has to be dynamic, otherwise inlets/outlets would be  
the obvious choice. Scripting the creation of inlets and outlets and  
connecting them wont work?

Im guessing that you dont want to use send/receive because more than  
one sub patcher will also get the message, or you want to send to a  
group of subpatchers at the same time, but not at once?

> I want to create local (private) connections between a parent patch  
> and its
> subpatches. Is there a method whereby send and receive objects can be
> privatized to a patch and its subpatches as does pv?
>
> I know about #0 but that is not doing the job.
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> www.timara.oberlin.edu/GaryLeeNelson
>
>

In what way not doing the job? This should work.....

Sorry if any of this seems obvious or if your problem is different, but i think these are all the things you need to consider when using #0

To use #0 you would need to load the patch by having it as an abstraction in another patch, or by sending load "mypatch" to pcontrol.

You also need to have it as the beginning of a symbol argument. You cannot just put #0 as your send name - max doesn't seem to like that!

If you have any abstractions as subpatches they will return a different value for #0 than the main patch which also could be a problem.

Other than these points I can't think of any other reason why #0 would not work. Maybe I've missed something....

The syntax is "parent::othersubpatch::foo"!

Am 18.09.2006 um 18:22 schrieb Gary Lee Nelson:

> That looks promising. What I really need is something that will send

> messages between subpatches. I can't seem to find the correct 

> message like "send parent othersubpatch::foo"

> That looks promising.  What I really need is something that will send
> messages between subpatches.  I can't seem to find the correct  
> syntax for a
> message like "send parent othersubpatch::foo"


On 18.09.2006, at 18:22, Gary Lee Nelson wrote:

wouldn't the new 'pattrmarker' object (found on jeremy's c74-sharing- 

> That looks promising.  What I really need is something that will send
> messages between subpatches.

wouldn't the new 'pattrmarker' object (found on jeremy's c74-sharing- 
page) help to make this even easier?

why can't you just use #1-type arguments to the subpatches? (if 

On Sep 18, 2006, at 12:33, Jeremy Bernstein wrote:

> The syntax is "parent::othersubpatch::foo"!

> Am 18.09.2006 um 18:22 schrieb Gary Lee Nelson:

>> That looks promising. What I really need is something that will send

>> messages between subpatches. I can't seem to find the correct 

>> message like "send parent othersubpatch::foo"

why can't you just use #1-type arguments to the subpatches? (if  
they're abstractions, obviously...)

> The syntax is "parent::othersubpatch::foo"!
>
> jb
>
> Am 18.09.2006 um 18:22 schrieb Gary Lee Nelson:
>
>> That looks promising.  What I really need is something that will send
>> messages between subpatches.  I can't seem to find the correct  
>> syntax for a
>> message like "send parent othersubpatch::foo"
>
>
>


> messages between subpatches. I can't seem to find the correct syntax for a

with the new pattrmarker and pattrforward it would work:

put [pattermarker othersubpatch] into your othersubpatch and send 

messages to the object named "foo" inside othersubpatcher with 

I don't need to send a patch, as the pattrmarker.help will do.

You should find it at Jeremy Bernsteins share page...

This is much more solid than pv, #1 and other old style ways to do it. 

Jeremy created the ultimate access to the only real local variables in 

(pv allows only one instance (undocumented) which is a shame...)

Gary Lee Nelson wrote:
> That looks promising.  What I really need is something that will send
> messages between subpatches.  I can't seem to find the correct syntax for a
> message like "send parent othersubpatch::foo"

put [pattermarker othersubpatch] into your othersubpatch and send 
messages to the object named "foo" inside othersubpatcher with 
[pattrforward ::othersubpatch::foo]

I don't need to send a patch, as the pattrmarker.help will do.
You should find it at Jeremy Bernsteins share page...
This is much more solid than pv, #1 and other old style ways to do it. 
Jeremy created the ultimate access to the only real local variables in 
Max: the object names...
(pv allows only one instance (undocumented) which is a shame...)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


I should have said that I UNDERSTAND #0. I was making a version of my

random objects entirely as abstractions. All of them share the same seed

which is easy in the external (recently posted). Without private sends and

receives I had to use pv and send through objects named #0sender and

#0receiver (or what ever names). I used a pv to broadcast the value created

Anyway, the problem is solved by updating my objects to UB with Xcode.

Still think private send and receive would be a good idea.

On 9/18/06 11:51 AM, "Alex Harker" wrote:

>> I know about #0 but that is not doing the job.

> In what way not doing the job? This should work.....

> Sorry if any of this seems obvious or if your problem is different, but i

> think these are all the things you need to consider when using #0

> To use #0 you would need to load the patch by having it as an abstraction in

> another patch, or by sending load "mypatch" to pcontrol.

> You also need to have it as the beginning of a symbol argument. You cannot

> just put #0 as your send name - max doesn't seem to like that!

> If you have any abstractions as subpatches they will return a different value

> for #0 than the main patch which also could be a problem.

> Other than these points I can't think of any other reason why #0 would not

I should have said that I UNDERSTAND #0.  I was making a version of my
random objects entirely as abstractions.  All of them share the same seed
which is easy in the external (recently posted).  Without private sends and
receives I had to use pv and send through objects named #0sender and
#0receiver (or what ever names).  I used a pv to broadcast the value created
to replace #0.

On 9/18/06 11:51 AM, "Alex Harker"  wrote:

>
>
>
>> I know about #0 but that is not doing the job.
>
> In what way not doing the job? This should work.....
>
> Sorry if any of this seems obvious or if your problem is different, but i
> think these are all the things you need to consider when using #0
>
> To use #0 you would need to load the patch by having it as an abstraction in
> another patch, or by sending load "mypatch" to pcontrol.
>
> You also need to have it as the beginning of a symbol argument. You cannot
> just put #0 as your send name - max doesn't seem to like that!
>
> If you have any abstractions as subpatches they will return a different value
> for #0 than the main patch which also could be a problem.
>
> Other than these points I can't think of any other reason why #0 would not
> work. Maybe I've missed something....
>
>
> Alex

> Still think private send and receive would be a good idea.

pattr system, especially pattrforward which can talk directly to named 

And pv of course... (might be short for private value)

Gary Lee Nelson wrote:
> Still think private send and receive would be a good idea.

pattr system, especially pattrforward which can talk directly to named 
objects...
And pv of course... (might be short for private value)

Private send & receive