I'm trying to map out what can't be considered a "constant" in terms of time, tempo, and sample rate.
Good thread here about why "real time" functions won't work for calculating durations/tempo: viewtopic.php?f=9&t=287
The short of it is that because audio buffers are processed in batches, it's not possible to rely on reading the current timestamp, as you can't guarantee the buffer is being processed in real time. I've specifically noticed this is relevant when doing a DAW export while using VM embedded as a VST. The timing isn't real time.
I'm wondering if there are situations where the sample rate might change as well after a module has loaded e.g. during DAW export or if the host software changes audio interface?. Is it a good idea to always call Values.SampleRate or Values.SamplesPerMs instead of "caching" the value? Are either of those calls "costly"?
Accounting for changing sample rate
-
- Posts: 31
- Joined: Mon Mar 08, 2021 12:28 am
- Contact:
Re: Accounting for changing sample rate
So far I've based all my time-related calculations on the 48kHz..
So when you divide 48000/frequency you get the number of counts to do in ProcessSample before a new event should occur...
And because internally this is what VM works with, this is as constant as can be..
I have not noticed any flaws with that yet...
So when you divide 48000/frequency you get the number of counts to do in ProcessSample before a new event should occur...
And because internally this is what VM works with, this is as constant as can be..
I have not noticed any flaws with that yet...
Request for Music