-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Higher Oversampling Options #308
Comments
Thank for the feature request! At the moment, we're using JUCE's built-in oversampling class which only supports up to 16x oversampling. I'd have to take a closer look at the implementation to see what it would take to extend that class to support 32x or 64x oversampling, but it's definitely worth a look. I'm a bit curious if you have any examples of settings/input signals that produce audible aliasing when the "Tape" section of the plugin is running at 16x oversampling? By audible aliasing, let's say any aliasing artifacts that are louder than -100 dBFS. |
Thanks for the thorough investigations! Going the through the screenshots in pairs: With the first pair of screenshots, it looks like going going from 16x -> 64x oversampling reduces the max aliasing artifacts from approx. -80 dB down to maybe -98 dB. So it's a slight difference, but it definitely is there. The compression is currently using it's own separate oversampling that is fixed (I think at 2x). Probably I should re-arrange some of the code so that the compression uses the same oversampling as the tape module. It definitely makes sense that lower bias levels would add more harmonics, which would result in more aliasing as well. Maybe another reason why having the 32x and 64x options could be helpful. Re: single- and double-precision processing, the plugin uses single-precision processing throughout most of the DSP. This is because for most of the processes there is either no difference or an extremely minimal difference between the results of those processes done with single- or double-precision floating-point math, and the single-precision math can be vectorized more efficiently leading to better performance and lower CPU usage. However, there are a couple of processes within the plugin where the extra precision is needed in order to achieve a more "accurate" sound, and for those processes, the plugin will internally switch to double-precision floating-point math. Anyway, I'm currently a bit busy trying to get the next release out for our BYOD plugin, but I'll definitely come back to this hopefully in a couple of weeks, and look at make some changes to the oversampling code. Thanks again! |
No, thank you! I'll check BYOD whenever It's ready and I hope you can make chowtape even better than It already is. |
Is your feature request related to a problem? Please describe.
The saturation is great, but certain parameters could benefit from a higher oversampling setting to fight aliasing in the signal.
Describe the solution you'd like
I would like to have higher oversampling options within the plugin (x32, x64 or even higher) specially for rendering.
Additional context
This plugin might be the most convincing tape emulation I've heard, and I feel that with a little more oversampling It could become almost indistinguishable from the real, modeled tape machine. I don't know how hard this would be to implement, so I apologize in advance In case It's too much to ask. I don't want to be entitled or unreasonable.
Thank you for all you do.
The text was updated successfully, but these errors were encountered: