mike_mccue
How do we find out if a dsp programmer has incorporated CPU saving short cuts and or round offs to their products' calculations? How do we find out what oversampling options are specifically doing with those calculations. For example; Is "2x" oversampling in a dsp residing in a 44.1kHz project actually using all the increments available in 88.2kHz or does that just bump it up to twice the detail of the actual calculations happening in the dsp?
For example; How do we know that a synthesizer isn't just grabbing every other sample from a stream and mashing stuff together into the "synthesis"? I guess we'd have to ask.
I would judge whether they took short cuts by ear. If something sounds good in the way that I use it, curiosity aside I don't really care why. And if it doesn't sound good, or something else sounds better, I wouldn't use it. And the "something else sounds better" is a big reason why it makes sense for plugin authors not to take shortcuts.
"Detail" isn't the right word. Higher sampling rates allow for higher frequencies and this drives the frequencies that will cause aliasing higher as well.
In an ideal world, CPU wouldn't be a limiting factor (and today it is much less than it was a few years back), and the plugins' authors would choose an appropriate sample rate to eliminate audible problems for the type of processing that they're doing.
Where it gets tricky is some things will only really require a higher rate with certain settings - i.e. a compressor may be absolutely fine unless you push it to really fast attack/release times and set the threshold so it's constantly crossing back and forth. So do you always oversample it and waste CPU for the 90% of uses where it will be fine, or never oversample and potentially get some unpleasant distortion with specific settings, or do you give the user a choice - knowing that most of them will have no idea when it needs to be turned on and when it will have no benefit?