multiple instantiations of my object shouldn't share the same memory

    Wes Jackson
    Feb 22 2011 | 1:01 am
    My object uses many variables and classes to process data. I want to be able to use several instantiations of my object for different tasks at the same time. However, multiple instantiations appear to share memory and variables. For example, my object does not permit data in inlet 3 until it has received input into inlet 1 first. Also, it does not allow inlet1 to be filled if inlet3 has not been correspondingly stimulated. Thus, it requires a specific back-and-forth input order before it can process data. This works fine with one object. But with two objects, this process becomes fuddled as object1 getting input into inlet1 prevents object2 from also getting stuff into inlet1. Keeping track of this is one boolean variable which switches between true and false, and is checked before any processing is permitted. Because all my other variables are declared like this (normally??), I infer they are susceptible to the same problem.
    Is there a general reason for this? How can multiple instantiations of an object keep to themselves?
    Thank you!
    • Wes Jackson
      Feb 23 2011 | 6:48 pm
      Thanks! Also, I have many classes containing other functions and variables, like such:
      class classA { classB var1; classC var2; classD var3;
      function1(); function2(); function3(); }
      such that further along are definitions such as:
      void classA::function1() { someVar; }
      I've tried moving all of these into the structure, but this doesn't seem to work. For example, there will be a compilation error at classA::function1() saying classA hasn't been defined. Also, it says someVar would not exist in the structure, although it should be accessing it from classA. What is done in these cases?
    • Peter Castine
      Feb 24 2011 | 4:19 pm
      If you are unable to cut the umbilical cord to C++, I would suggest taking a look at Thomas Grill's flext library, which provides C++ classes for building externals. As gravy, it lets you build Max/MSP and Pd externals with the same code.
      Frankly, it's easier in many ways to stick with ISO-C for developing Max/MSP/Jitter externals. But if you're welded to C++, than take a look at flext. Even if you don't use it directly, you can probably find the solutions to all your problems there.
    • nick rothwell / cassiel
      Feb 25 2011 | 12:33 pm
      To differ slightly in opinion from Peter: I've been doing externals in C++ (both Mac and Windows) and have found that everything hangs together pretty neatly. (I write pure C for the main Max file, but everything else is C++.) The only immediate downside I can see to using C++ is knowing what the various object allocation/manipulation routines might do in the scheduler thread, but that's an issue that you need to think about in the plain old C world as well.
      It sounds to me that Wes's original problems to do with accidental data sharing would also happen in C - perhaps with greater frequency, since there's less support for proper encapsulation.
    • Wes Jackson
      Feb 28 2011 | 1:03 am
      hmm, I'm confused as to how flext would help? I read an intro 'manual' and it introduces libraries, which appear to permit multiple objects running indepently at the same time. But I'm confused as to what a library is extactly. Is this the case, and is this the only way to fix the problem? It seems intuitively like there should be a simple way to allow multiple objects to run independently of one another, but idk...
    • Wes Jackson
      Mar 02 2011 | 5:48 am
      Ahhh thanks, I'll try that! Sorry for not catching that first; I thought I'd used 'collect' as my skeleton so I figured if anything was relevant it was already in there, but it turns out I'd used 'buddy' instead...