Dynamic Oversampling up to 128x or more
-
As I see only up to 16x oversampling is available in scriptnode? Is it possible to make 128x (or even more) with scripting?
Or @Christoph-Hart can you add more options for oversampling please? Probably a dynamic oversampling node (OFF, 2x, 4x, 8x, 16x, 32x, 64x, 128x, 256x... modes in one node) would be great ;)
(Some current products uses up to 1024x dynamically)
-
@orange Yes dynamic oversampling is on my TODO list (I think I have started it already, but it's not quite ready yet.
Personally I think anything above 16x oversampling is just burning CPU (and at some point the memory will blow up), but nothing stops you from changing the code and adding more numbers.
-
Can't wait for this one
-
@Christoph-Hart said in Dynamic Oversampling up to 128x or more:
Personally I think anything above 16x oversampling is just burning CPU (and at some point the memory will blow up).
Some wave shaper functions are consuming not even 1% CPU with 16x oversampling on the compiled plugin. But also at the same time, some aliasing (low, but not negligible) still happens even on 16x above the Nyquist.
So the user might go for higher rates for cleaner solutions, if the DSP doesn't involve heavy CPU tasks. Besides, since the CPU technology's been going to a good way like Apple Silicon, why not use 256x if the user wants ;)
-
@Christoph-Hart When will it be ready?
Is it possible for you to add this dynamic os node as soon as possible please? -
The dynamic oversampler has arrived (
container::oversampler
). -
@Christoph-Hart said in Dynamic Oversampling up to 128x or more:
The dynamic oversampler has arrived (
container::oversampler
).Wow! Thank you!
-
@Christoph-Hart said in Dynamic Oversampling up to 128x or more:
The dynamic oversampler has arrived (
container::oversampler
).Trying to compile the current commit, getting these errors:
No template named 'parameter_node_base'; did you mean 'pimpl::parameter_node_base'?
'hi_zstd/hi_zstd_3.mm' file not found
-
@Steve-Mohican It seems the code is missing a few pimpls :)
-
@d-healey Should be fine now. The other error is a glitch, make sure you do a clean rebuild.
-
@Steve-Mohican It seems the code is missing a few pimpls :)
@d-healey I guessed that too but I just wanted to be sure :)
@d-healey Should be fine now. The other error is a glitch, make sure you do a clean rebuild.
@Christoph-Hart Thanks.
I think
no_mod_normalisation(getStaticId())
(212th line) also needspimpl::
prefix too?How can we use this node? There is no option for the oversampling rate selection.
-
@Steve-Mohican Click on the parameter icon of the oversample node.
-
@Christoph-Hart I can't see the options for higher than 16x oversampling rate. When the parameter range is increased, the node doesn't seem to work more than 16x. Can you add more rates please (yes the ram can blow up for some DSP codes but it will be fine for some cheap DSP codes) which is also requested in this topic?
One more thing about the latency. While the oversampling rate changes, will the delay compensation adjusted dynamically?
-
@harris-rosendahl There‘s not delay compensation going on, you need to do this manually.
You can enable 32x oversampling by changing the source code but that‘s the highest that the JUCE oversampler can do.
-
You can enable 32x oversampling by changing the source code but that‘s the highest that the JUCE oversampler can do.
Thank you for the info. Can you add 32x rate too please? It would be good at least we have 32x without being have to change the source code.
-
@harris-rosendahl I just took a look and the JUCE oversampler actually only supports 16x:
The exponent need to be smaller than 5, so 2^4=16x is all you can get here.
-
Hi guys, interesting subject. OS for higher than 16x can really be interesting for heavy saturation processors, i'm guessing 32 and 64x would completely remove any aliasing there is even in heavy situations.
Is there a way to overcome this Juce limitation?
-
@fastermaster 64x oversampling? I'm trying hard to hear a difference between 2x and 4x from what I saw in videos on that subject. Can it really be worth to force a processor to run a audio thread on 64*44100(or more) samples? Unfortunately I can't test this myself with my old machine but I highly doubt there's a good reason for oversample with such a high rate. No offense, just being curious…
-
@Frankbeat @fastermaster In fact one of the most important things in oversampling is the quality of the stop band filter.
a 16x OS with a good rejection has nothing to be ashamed of when compared to a 64x with a lesser rejection quality.
Unfortunately, the Juce filter doesn't appear to be that good, so I can understand the limitation to 16x might be problematic in some situations (though I haven't checked against another one) -
@ustk there are multiple filter options available in the JUCE sampler and I just picked one without giving it too much thought, so if you find parameters that sound better I'm happy to add those as options.