multiple complex instances.

    Apr 17 2006 | 6:48 am
    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. -matt

    • Apr 17 2006 | 7:12 am
      > 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!
    • Apr 17 2006 | 7:54 am
      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
      -matt (4.5.7)
    • Apr 17 2006 | 11:10 am
      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"
    • Apr 17 2006 | 2:47 pm
      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.
    • Apr 17 2006 | 5:17 pm
      > 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. -matt
    • Apr 18 2006 | 2:39 pm
      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
    • Apr 18 2006 | 5:24 pm
      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.
    • Apr 19 2006 | 12:27 am
      > 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
    • Apr 19 2006 | 3:47 am
      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.
    • Apr 19 2006 | 7:47 am
      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.