Matthew Aidekman

so I have this patch... it's not huge but very complex. It includes 

pattrs fun, lotsa s/r buses , many value objects, abstractions with 

but I want to run 3 or 4 of them. Sticking this thing in a poly~ or 

vst~ or abstraction would be like fitting a cow into a thimble 

Is it safe to compile it as an application and duplicate it 3 or 4 

so I have this patch... it's not huge but very complex. It includes  
pattrs fun, lotsa s/r buses , many value objects, abstractions with  
crazy arguments etc.

but I want to run 3 or 4 of them.  Sticking this thing in a poly~ or  
vst~ or abstraction would be like fitting a cow into a thimble  
labeled "don't put a cow in here"

Is it safe to compile it as an application and duplicate it 3 or 4  
times? (or a better way to do this?)

multiple-complex-instances

well, it does work if you append #1 to #0- (the trick is the minus 

sign, for some odd reason i don't fully grasp)

i don't know if this is what you need, but i use it like that when 

well, it does work if you append #1 to #0-  (the trick is the minus 
sign, for some odd reason i don't fully grasp)

i don't know if this is what you need, but i use it like that when 
dealing with multiple instances.

the minus character is a dash right? (I have no exclusive minus key)

I can only get the first one, the rest stick with the # in my 

WHAT? WHO??? WHERE?!?! NAW!
like   "     send #0-#1joe   "      ??
the minus character is a dash right? (I have no exclusive minus key)
I can only get the first one, the rest stick with the # in my  
abstractions.

tried:
#0-#1
#1-#0
#0-#1-#2
#0.#1
#1.#0
#0-#1-moo

i think the idea is that you'd use [forward] instead of [send]. using 

max, concatenate the arguments into one using your preferred method, 

prepend "send" and feed that to the forward object.

same for an empty [receive ], but with "set" instead of "send"

i think the idea is that you'd use [forward] instead of [send]. using  
max, concatenate the arguments into one using your preferred method,  
prepend "send" and feed that to the forward object.

same for an empty [receive ], but with "set" instead of "send"


exactly. i also meant using the [append] object, not append it in the 

same mssg box. basically, you would have something like (#0-)--[append 

#1] . but you gotta make sure to concatenate both so you don't have the 

exactly. i also meant using the [append] object, not append it in the 
same mssg box. basically, you would have something like (#0-)--[append 
#1] . but you gotta make sure to concatenate both so you don't have the 
space in between.

> you would have something like (#0-)--[append #1] . but you gotta 

> make sure to concatenate both so you don't have the space in between.

ok got it. Unfortunately this would be like a couple thousand 

objects on top of my already bulking infrastructure. doesn't seem 

like a good use of max ( although that might be my perception) looks 

> you would have something like (#0-)--[append #1] . but you gotta  
> make sure to concatenate both so you don't have the space in between.

ok got it.  Unfortunately this would be like a couple thousand  
objects on top of my already bulking infrastructure.  doesn't seem  
like a good use of max ( although that might be my perception) looks  
like I'm copying it in the finder.

That wouldn't help, even several instances of a standalone would share 

Actually the label at poly~ as far as I've seen it says: stick a cow in 

But with poly~s it the same, your infrastructure needs to deal with 

several instances no matter how you do it, you need to do it. just 

several instans of the main patch within a main main patch is way more 

effective than several instances of the Max program at the same time... 

(Or to come back to the picture: stick only one cow into the operatimg 

system of your choice, more will bite each other and finally die from 

That wouldn't help, even several instances of a standalone would share 
the same names.
Actually the label at poly~ as far as I've seen it says: stick a cow in 
here...

But with poly~s it the same, your infrastructure needs to deal with 
several instances no matter how you do it, you need to do it. just 
several instans of the main patch within a main main patch is way more 
effective than several instances of the Max program at the same time... 
(Or to come back to the picture: stick only one cow into the operatimg 
system of your choice, more will bite each other and finally die from 
overpopulation. ;-)

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

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

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

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

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


Actually, I've had some success with running multiple standalones. Each instance of the Runtime gets its own PID, memory, and all that stuff, and it works pretty well. The OS is left to deal with priorities, which it seems pretty well designed to do (at least if you're using OS X). I did this to help further separate midi and audio stuff. Worked fine. Anyway, in my situation I was dividing up a single big job into smaller jobs. So it might not be as good when you're dealing with identical applications doing the same type of job. Just try it. You never know, maybe it will do the trick!

Actually, I've had some success with running multiple standalones. Each instance of the Runtime gets its own PID, memory, and all that stuff, and it works pretty well. The OS is left to deal with priorities, which it seems pretty well designed to do (at least if you're using OS X). I did this to help further separate midi and audio stuff. Worked fine. Anyway, in my situation I was dividing up a single big job into smaller jobs. So it might not be as good when you're dealing with identical applications doing the same type of job. Just try it. You never know, maybe it will do the trick!
J.


> That wouldn't help, even several instances of a standalone would 

For the sake of onlookers and future researchers, stefan is referring 

to duplicating standalones in the finder. building several times 

with different names will yield separate name spaces in each program.

When I find my-self at a dead end on the list, I usually make a 

Variable, send, recieve, pattr and other namespace objects might 

benefit from a scope-mode attribute. in javascript the scope of a 

variable is limited to the highest function with a declaration. in 

max the scope of a variable would be limited to the highest patcher 

OR: remember kids,don't be like me, plan your programming project.

> That wouldn't help, even several instances of a standalone would  
> share the same names.
For the sake of onlookers and future researchers, stefan is referring  
to duplicating standalones in the finder.  building several times  
with different names will yield separate name spaces in each program.

When I find my-self at a dead end on the list, I usually make a  
suggestion. (because its fun)
Variable, send, recieve, pattr and other namespace objects might  
benefit from a scope-mode attribute.  in javascript the scope of a  
variable is limited to the highest function with a declaration. in  
max the scope of a variable would be limited to the highest patcher  
with a declaration.

OR: remember kids,don't be like me, plan your programming project.
-matt


Multiple instances is do-able on OS X, though you have to be careful about the names of any MIDI ports created or files saved, etc. There is some CPU overhead associated with each instance that you don't get if running a single modular app.

My solution to the problem of needing send/receive objects with multiple concatenated arguments has been to make an abstraction (named r. or s.) that scripts the appropriately-named send or receive into place internally, based on the arguments supplied to the abstraction.

Works well, but the downside is that you can't get a menu of sources/destinations by clicking on the abstraction, and it can be a little squirrelly when trying to include the abstraction in a collective or standalone.

The forward object is certainly simpler, but also more CPU intensive if you're pumping a lot of data through a lot of instances of forward.

Alternately, you could perhaps look at a js object that replaces itself with the appropriate send or receive, I seem to remember that this was possible.

duh... I think I've been caught "skimming". I didn't realize your problem was with namespace (don't know how I missed that, mind you). However, the multiple standalone thing will still work. As has been pointed out, you'll need to compile each instance with a new name. I also jazzed this approach up a little by using Topher's syscommand mxj to launch the other standalones after my primary app launched. Neato.

multiple complex instances.