Grimm

what is the best way to manage send objects?

Is there a way to, say, hermetically seal a subpatcher so that its sends only operate internally (so that it wouldn't send or receive information to and from other subpatchers)?

looking for ideas about ways to ensure that when using lots of subpatchers, sends don't accidentally have the same name, etc...

hi!
what is the best way to manage send objects?

looking for ideas about ways to ensure that when using lots of subpatchers, sends don't accidentally have the same name, etc...


better-management-of-send-and-receive-objects

If you prepend #0 to your send/receive names, the #0 will be replace by 

Centre de Recherches et de Formation Musicales de Wallonie asbl

If you prepend #0 to your send/receive names, the #0 will be replace by 
a unique id at instantiation.
See Max' tutorials&topics, p.420

_____________________________
Patrick Delges

Centre de Recherches et de Formation Musicales de Wallonie asbl
http://users.skynet.be/crfmw/max


prefix the name of the send and recieve with #0

refer to the max tutorial and topics, the chapter on "arguments, $ 

prefix the name of the send and recieve with #0
#0 is a unique number for each patch.
refer to the max tutorial and topics, the chapter on "arguments, $  
and #"
-jennek


Try using pvar instead of send / receive.

"pvar does not work globally (as send and receive do). The pvar object and

its associated object must be in the same patcher."

Try using pvar instead of send / receive.
"pvar does not work globally (as send and receive do). The pvar object and
its associated object must be in the same patcher."

three technologies come to mind: #0named send/receives, pvar and pattr.

#0naming is just making sure you have unique names for different 

instantiations (looks ugly but works flawless).

pvar is straight forward, but only allows one instance per object. 

(still hope this will change in the future)

pattr is much more universal, but has a learning curve. But at the end 

you also have tools to manage presets which make it worth to look into.

[][] [][][] [][] [][][] [][] [][][] [][] [][][]

[][][][][][][][][][][][][][][][][][][][][][][][][][][][]

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France

#0naming is just making sure you have unique names for different 
instantiations (looks ugly but works flawless).
pvar is straight forward, but only allows one instance per object. 
(still hope this will change in the future)
pattr is much more universal, but has a learning curve. But at the end 
you also have tools to manage presets which make it worth to look into.

  [][]  [][][]  [][]  [][][]  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x---
--_____-----------|----------
--(_|_ ----|-----|-----()---
-- _|_)----|-----()----------
----------()------------x----

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France
Phone at CCMIX   +33-1-49 77 51 72


> pvar is straight forward, but only allows one instance per object. 

> (still hope this will change in the future)

I often use multiple instances of pvar per UI object and have been doing 

so for a while now. I'm currently at Max/MSP 4.5.5 (win), unless I 

absent-mindedly updated and forgot about it. Seems to work just fine.

> pvar is straight forward, but only allows one instance per object. 
> (still hope this will change in the future)

I often use multiple instances of pvar per UI object and have been doing 
so for a while now.  I'm currently at Max/MSP 4.5.5 (win), unless I 
absent-mindedly updated and forgot about it.  Seems to work just fine.


I had bad problems which I reported (basically making the connection 

only with one pvar unless I recreate a the not connected pvar), and the 

answers from cycling acknoldeged the problems but did not give them a 

Now I only use pvar if I come along with a single one.

If the fix is in the to do list, I'd add my request for the ability of 

adding also multiple inputs to pvar to make it accessible for objects 

like filtergraph~. Either by defining it with a third argument or simply 

I had bad problems which I reported (basically making the connection 
only with one pvar unless I recreate a the not connected pvar), and the 
answers from cycling acknoldeged the problems but did not give them a 
high priority for fixing.

Now I only use pvar if I come along with a single one.
If the fix is in the to do list, I'd add my request for the ability of 
adding also multiple inputs to pvar to make it accessible for objects 
like filtergraph~. Either by defining it with a third argument or simply 
create as many inlets as outlets.

don't forget sending to subpatches with erm, is it pattrhub? like if you had a flonum named f[1] in a patcher named fux0r, you could send pattrhub something send f[1]::fuxor 0.342 or so, can't remember the syntax exactly. Of course, f[1] needs to be erm, assigned to a pattr or just drop an autopattr in there. quite useful.. yet inherently gay. We should have a #-1 argument or so, something that lets you just send to whatever page you're no, regardless of whether its in an abstracted external, cause I noticed that erm, #0 won't work with patcherargs... eh, I guess its better to use abstractions anyways as opposed to just plain old patchers if you plan on having multiple instances. woah, its 3am. hrm, ok.

don't forget sending to subpatches with erm, is it pattrhub? like if you had a flonum named f[1] in a patcher named fux0r, you could send pattrhub something send f[1]::fuxor 0.342 or so, can't remember the syntax exactly. Of course, f[1] needs to be erm, assigned to a pattr or just drop an autopattr in there. quite useful.. yet inherently gay.  We should have a #-1 argument or so, something that lets you just send to whatever page you're no, regardless of whether its in an abstracted external, cause I noticed that erm, #0 won't work with patcherargs... eh, I guess its better to use abstractions anyways as opposed to just plain old patchers if you plan on having multiple instances. woah, its 3am. hrm, ok.

whoops, seems my reply above was offensive to some people. Sorry to those that I caused any anguish to. I will be more civil and less erm, of myself ;) in future responses. Sorry again,

> whoops, seems my reply above was offensive to some people. Sorry to

> those that I caused any anguish to. I will be more civil and less

> erm, of myself ;) in future responses. Sorry again,

Main problem of replies like that is, that I don't know to what you 

reply, might be less of a problem within the forum, but on the list its 

hard to know. A short quote of the message you are replying to would be 

always helpful. (There is a lot "above" which is not related to your post)

bine~ wrote:
> whoops, seems my reply above was offensive to some people. Sorry to
> those that I caused any anguish to. I will be more civil and less
> erm, of myself ;) in future responses. Sorry again,

Main problem of replies like that is, that I don't know to what you 
reply, might be less of a problem within the forum, but on the list its 
hard to know. A short quote of the message you are replying to would be 
always helpful. (There is a lot "above" which is not related to your post)

better management of send and receive objects...