Best way to reinitialize dyn alloc'ed vars in MSP external after attr changes?

Jun 24, 2013 at 10:07pm

Best way to reinitialize dyn alloc'ed vars in MSP external after attr changes?

I’ve written an MSP external object with a fairly intensive initialization process that involves dynamically allocated memory. I’ve hard-coded parameters while I was getting everything working that now need to be user-configurable while the patch is running. Unfortunately all of the initialization is taking place in the *obj_new() function at the moment, which I just realized is a bad idea for my purposes.

I am thinking that making use of attributes is the friendliest option for parameter setting because I plan on having users make use of the Runtime and not full Max.

What is the best way to proceed?

My thought so far is to put a (memory free/re-initialization) function into the obj_dsp64() function right before I add the obj_perform64() function to the signal chain. I would overload the attribute accessor functions to require a memfree/re-init if they were changed by flipping an “attribute changed” bool. If there is some initial loading time on start each time attributes are changed I don’t mind.

My question is… does this sound completely idiotic? Is it memory/thread safe? Is there a better way that I should attempt?

I read a lot of great answers to other questions I had on this board… hoping someone stops me from doing something stupid :P

Jun 24, 2013 at 10:31pm


What kind of heap allocated attribute do you need ? Arrays of longs or/and doubles ? Or something else ?

Jun 24, 2013 at 10:56pm

2-dim arrays of doubles and ints, with a lot of iterated calculations over them to pre-game the object for calculations in the perform update.

Jun 25, 2013 at 2:40am


1. IMHO avoid to use allocation/deallocation at all. Use a local pool and limit the attribute memory consumption.
2. You scenario seems “safe” but the problem is that changes will be considered only when the DSP chain is rebuilt (that means never in Runtime if you don’t switch off/on the DSP).
3. You could use a “Lock-Free” structure ; but i don’t not know (at least never used) a library with Lock-Free resizable array.

Anybody else ?

Jun 25, 2013 at 7:29am

1.) Yeah, I definitely avoid alloc/dealloc except for the init

2.) My plan was to dynamically disable the ability of the user to change anything while DSP is switched on. I was going to do that regardless of the implementation. I want the user to set everything up, turn it on and leave it.

3.)Lock-Free structures sounds interesting. I had to look them up and it might be too complex to handle for me at this point, but maybe some time in the future :)

Thank you for replying Nicolas!


You must be logged in to reply to this topic.