Why are sampleRate parameters throughout JUCE floating point instead of integer? Are there any situations where sample rates are non-integral?
Generally not, but there are a few situations where third-party stuff expects a float, so I figured it was easier to just use it everywhere. Also makes it a bit easier to do maths with them.
Aren’t there non-integer sample rates for working with video pull up and pull down rates?
Matt
[quote=“matt”]Aren’t there non-integer sample rates for working with video pull up and pull down rates?
[/quote]
Yes, but those are video frame rates, not audio.
[quote=“jules”]
Yes, but those are video frame rates, not audio.[/quote]
Sure, but aren’t there also corresponding audio sample rates?
http://www.mackie.com/support/faq/pullups_pulldowns.html
There’s a table on that site that shows non-integer sample rates used for certain applications (for example, NTSC pull-up).
Matt
[quote=“matt”][quote=“jules”]
Yes, but those are video frame rates, not audio.[/quote]
Sure, but aren’t there also corresponding audio sample rates?
http://www.mackie.com/support/faq/pullups_pulldowns.html
There’s a table on that site that shows non-integer sample rates used for certain applications (for example, NTSC pull-up).
Matt[/quote]
Well, that’s news to me! Every video editing system I’ve seen has just treated the video and audio tracks separately and used standard sample rates for the audio.
It’s well outside my field of expertise; I could be wrong. I just meant to point out that there are documented use cases of non-integer rates.
Matt
As far as studio usage goes, I’ve only heard of non-integral rates applying to video post-production and the final video rendering stage, basically as matt pointed out.
However, in the pure studio audio realm, non-integral sample rates are entirely non-standard. I’ve never seen such used in pro recording and output devices, and not even in home consumer sound cards.
I’d suggest leaving it in case someone does start messing with digital video alongside JUCE.