just wondering if anyone run into this issue? i notice that rack::settings::sampleRate returns 0 when my code is compiled on a windows machine. this works all well when i dev in macOS.
any idea surrounding this? I really don’t wanna hard code sample rate into my code.
thank you for your response. Yes, i understand that. the issue im running into is that when i use debug to print my sr variable where rack::settings::sampleRate is stored, it’s reporting back zero in my log, thus rendering code down the line to have inf. I didn’t have this issue when i run my plugin on macOS.
Oh yep Jon, I’ve seen you don’t have this issue from MacOS, but from Windows.
Really I can’t help you because I don’t use/have Mac. Hope somebody will help you here!
Cheers from France.
Dominique.
EDIT/ADD: perhaps from Windows, the sound system (driver) can’t be established (in case you’re using Windows WDM + ASIO drivers). Like a Rack without AUDIO-x output module, the sampleRate is… zero! (really), and by the way, timings are erratic, until you place and configure correctly the AUDIO-x module into the rack!
The current sample rate is given by AUDIO-x module! without it (or if not fully configured), sampleRate = 0
On Windows platform (IDK on Mac or Linux to be honest)
yup i found a solution towards that, not the most efficient but will work out from there. i’m used to initialising with sample rate and buffer size as with how audio plugins do. so the current solution is during the module constructor, i call APP->engine->getSampleRate()
then have an onSampleRateChange function to update if users change in settings.
These are cases during initialization, before process() is called, that APP->engine->getSampleRate() returns zero (on Windows). (and apparently some other cases).
I’m expecting Rack at some point to call onSampleRateChanged() once it gets the actual sample rate. I’ve seen a number of sample-rate-dependent modules that don’t implement onSampleRateChanged and hard-code 44.1 or 48k.
process() is absolutely the wrong place to allocate buffers based on the sample rate/time passed to it. That’s what onSampleRateChanged is for.
Yes, I’ve noticed that initial calls to process() may have a args.sampleRate of zero. My solution has been to wait until it’s not zero before using it. This is on Windows.