multiple complex instances.
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?)
I wish #0#1 worked.
> I wish #0#1 worked.
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.
hope this helps!
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
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
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
like I’m copying it in the finder.
I deeply appreciate your help.
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
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
   
\ /|() ()|
))))) )| | |( \
/// _/)/ )))))
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!
> 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
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.
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.