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
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 :)
Thank you for replying Nicolas!
C74 RSS Feed | © Copyright Cycling '74