OK, to the first sentence, if a process needs it, the process probably needs to do it. So I'm not sure what "isn't the way to go about it" means, for most cases that a developer would use it.@midnight wrote:Some developers have said that realtime oversampling in plugins isn't the way to go about things. The reason is usually that "resampling is an intensive process best done offline" and that doing it with low latency will result in sub-par sound quality.
About latency, I guess that you mean, for most folks, latency in addition to host buffer latency, and in a live-monitoring situation where latency compensation is not a fix. Obviously it's a lot bigger (relative) deal if you're talking about a sample-at-a-time system like Pro Tools in hardware.
But the latency doesn't need to be all that extravagant, even for linear phase, with a multirate oversampling. Again, if the oversampling is needed, well, it's needed.
And of course there is some measurable degradation, just as their is doing finite precision calculations in general—filters, whatever. My earliest commercial product with oversampling was Amp Farm, first released in 1996, and the horsepower on the Digi hardware back then was pretty pathetic by today's standards. Sure, that's an amp simulator and not hi-fi, but the point is that you make the trade-offs and you get the job done.
In the end, if the plug-in doesn't sound good, don't use it, and if it does, use it. There is nothing made for audio that doesn't have tradeoffs. Certainly the antique gear that we prize today (consoles, LA-2A, etc.) are far from perfect. And we don't prize them because they are old, we prize them because they sound good and survived the test of time. Other old stuff may have made different tradeoffs that people didn't like as well, and they faded into obscurity. Let it be the same with the digital stuff.