I’m on my phone – thanks for the correction. Instead of calling back to the engine, doesn’t the event contain the sample rate? Events usually contain all the relevant information for the event.
I’ve never used onSampleRateChange because pretty much all my modules that have sample rate dependent initialization also have user configurable over sampling, which also changes effective sample rate. I need my own code to detect over sample rate changes and I prefer to keep all the sample rate logic in one place - generally at the top of my process code.
I’ve been using onSampleRateChange to recalc any clock dividers. Is there any reason to calculate user interface values any faster just because someone wants a jigahertz sampling rate? Or is that an optimization that most people ignore?
By using call from module’s constructor (the second example I’ve mentioned), this avoid potential unintialized sampleRate / sampleTime on early DSP frames, it’s a kind of “guard” to prevent bugs (or possible module + Rack crash). Same about 3e37 insane value, in case the sameRate is… 0.f ! (I’ve already seen this scenario during debug session on Windows platform, but many months ago - perhaps this was fixed by most recent SDKs, but I’m not sure). Constructor is invoked once, so it’s more reliable and doesn’t impact module’s performance.
Also by changing AUDIO module settings this impact the DSP (at least for seconds).