November 5, 2014
Hi Will and Tom,
I have a question about the conventions of using a combination of the constructor and prepareForPlay() functions. As I go through the examples in the FX book, I notice that some functions placed in prepareForPlay() don’t seem necessary. I was wondering if it’s just good practice to include them there as well, or if there might be another reason to include them.
For example, when you code an EQ, and you have a function calculating the biquad coefficients. If you add this function in the constructor and in userInterfaceChange(), there would be no need to add it to prepareForPlay(), would there? (as long as you do flush the delay elements here).
All the best,
EDIT: I guess in this example it has to do with updating the samplerate in prepareForPlay(). That should answer my question in all cases I think; I'll check Does that mean that if you have a function to calculate the value of some variables which includes the samplerate in its calculation, you never include this function in the constructor?
January 29, 2017
Yes, anything that is sample rate (or bit-depth or channel count) dependent or anything that must be cleared/reset/recalculated out on a per-run basis needs to be updated in prepareForPlay().
The filtering objects have their default sample rate set in their constructors, so initializing them in the constructor of the plugin is OK - they won't have garbage or 0.0 coefficients. I almost always initialize every member variable in the constructor, even if I know the value will get overwritten later.
November 5, 2014
Thanks, that’s very helpful I have written some classes of my own the last couple of weeks. They do the job, but sometimes I get a bit confused with these class-within-class structures haha. I will implement a default samplerate too then in my classes when appropriate… Good to know that it’s not strange to initialize variables even when you know they will be overwritten. Better safe than sorry!
All the best,
April 3, 2014
not only is it "ok" to initialize variables in the constructor but it actually is a must Depending on your compiler and warning level it will output a warning if you don't do it. Some programming languages won't allow at all to leave the constructor without having touched all variables (or they have a built-in initialization).
In general your objects must/should not ever be in an undefined state but which is what happens if you don't intialize variables. "Interesting" things can happen this way, so better get into the habit of initializing everything always
C++11 allows you to initialize basic types directly with the declaration (e.g. int m_myVar = 42;). This way you can initialize stuff correctly without explicitly implementing a constructor at all (of course this works only for simple classes).
Most Users Ever Online: 36
Currently Browsing this Page:
Guest Posters: 1
Newest Members:strings4v, TheSmile, semihyavuzz, alfredLue, danioc, midnightskate3, Alia5, Shamal Sundar, Walker, Brad
Moderators: W Pirkle: 208
Administrators: Tom: 67, JD Young: 80, Will Pirkle: 0, W Pirkle: 208