jamaalsd

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.

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

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. 

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


best-way-to-reinitialize-dyn-alloced-vars-in-msp-external-after-attr-changes

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.

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 :)

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 :)

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