Why is my filter band moving when adjusting oversampling factor?

[HISEnberg]

@Straticah It largely depends on the filter design, but I think the frequency-split template uses one-pole, so each frequency is doubled. So a LPF of 200Hz becomes 400Hz.

Maybe try one of the other filter types in Scriptnode, I am not sure but one of them may be sample rate agnostic. Another alternative is to just process whatever comes after your multiband process with the oversampling. A last alternative would be to compensate for the oversampling, dividing or multiplying the Frequency cutoff by a factor of however much you are oversampling.

So on a LPF, 2x oversample, if your frequency was initially set to 200, it should become 400. Divide the control by 2 to compensate and set it back to 200.

[HISEnberg]

Also I am not 100% sure this is exactly what is happening in your situation, but just a semi-educated guess.

[Straticah]

@HISEnberg yeah makes total sense to me. In my mind samplerate and poles were not directly connected but it seems to be like that. I am not able to use anything else than LW filters unfortunately.

Any experience on reducing CPU impact of oversampling containers?

I would have 4 separate container one for low, mid, high, master softclip.

Hope this is not more of an impact as wrapping the plugin into one.

[HISEnberg]

@Straticah Realistically I don't think there is a way of reducing CPU for oversampling, except by using the minimum amount of the oversample container as possible. I think trying to compensate with some math might be a solution.

[Straticah]

@Christoph-Hart any suggestions to keep the oversampling containers to a minimum while not processing the filters of my example since they behave that way?

[Matt_SF]

@Straticah The filter curves are moving but it doesn't change the sound. It seems to be affecting the display only:

HiseSnippet 1868.3oc6YszaiTrEtZmTwSx.bGP73tzKXQ3pQQocd3YDKhyKCQPRrFGBrK2JcWcbOt6pZ5tbRLOVgtRvOAVwVX48evcAhcHgDKQBwFVvt4WvENUWcaWkcmLNdlDDOBRHWm5TU8cNmuyop9LMi4NzjDdLxZtC5EQQVOCtUOln8lsI9LzNagrdN7tjDAMthRzF8hHIITWjk0TugTf0rSiR+6QqsAIfvbnCDgPGx8cnusenuXfzl0eK+ffFDW5A9gZZub8cb3rM4A7t.dlBuHJh3zgbBcOhTsRXzaRRZir9W36uxJ1DWuZd1KYe+ic8bnKUawUWtVUxJ2yyq1h1KujaMukAPNy1t9BdbKAQPSPVSuA2sWq17yXpC3P+D+iCnxA1nVvIqD2fG3JMQ4uQa11OvsYtiJAgrvMG31lR41dQ7t9t98kOv8cmzIpLXE5NPqRlvaJC3YqCuE0fWAPxRCRSqfzyia4D6GIFLiDO2FuCChldDHNoCEktHq+GdSNn.SrPHoCsQLLn+Ble0EW7tUf+2q85dcYNBeNqBmsGWP2mM+qM2GN2ry8wyUY3o77JbN4wDyCBnwENsjZDeYKbdV2viow2sxojftz9JBluoOEew9T8Ptixp0Tjy1g4K1OhlMdTuNJyUA+5c1YKhfHCDYx.8hnwBeIDr1hdJjFnBKyh2hlzQvifDgQhY.ag61MfHLoPxDsrI.efQbSFbXI9hd5IhCyqld73UCn8EZsiIbedbSegS6hwaoBvK30ttwaVV5yh21yi5HF.1owMduatTx4xRIgyTd3OS1vJMdO6BSF+T7.heTLMhDSOf2Lfza9DRXT.8A.FuakiC3NcZ4+AzQyVhTPXCoFy6zlvXzfjIIoZlw1qXeodEzC3cE9rS1kHh8OGxN2qaXKnduCcyLzAxrJIysTiWTNVxQZQYtoC9U3urIskisxlzNeRszx8nhy3wcRCGY+FYUV46SRcxG4ctMZ8f.9YaxCi7yXrPLHUVSdPun1bluiTjRibjtdHuKbHYvEtZ5.hefjh2paBTzvceVKP4z6Csl5PZbR5FWFu3Bv+AT983tvTkaPb.GaulDQaYtirNDPNowK3zmjZfUcdhbKxuuT4k.HFJMc4skx3SSRLb4IT+VVFpj5hTisyZJsJUJRqbDjdVRcz6jbnbVGR.5PIoPtOH4AKUOyHlQp5svm6A2oGiLrn6jZQ.0ZgrYMveJd5uvK2bFBokFBo+CIURyby.qJ5fFR4YjEtn45bK7aCdbRLviNSV55.R7ITQ5gnKHq5NillzjXNLyWriqb6b6FF1aUTezHkVFqNMzSvVV6B1RMyVFByGA14t9rLibP01cImOjrGsVKAMRVBQWuVcnmohk5ZJce4Gb+s4yV+e+yO5+7KqgxH0JpC+T.QoEpL4DurFKWSmmFLass6IiYaoYIOK1Kl99GkDE3KVBcgIroyW.1Fe6RYElGGXFWTzs7nQ2kqORz8S+95O9n629Q+RsOI7aWSkHuAg4VwdP38G+5l+2e3++U0WuqfGB2.jdS9vL2RExbKiChsOZESh6swM.KrKTbrW5inJdYUuzkUTInx3iAjuJ5wTS8pFPx2Vk1ZGZY0gprPiC8kvOzMIZgGF3y5.46ePLbUPOiBbyNyYm74+p7.yeFCbqpFvJBFpCxjXKwKP2OO+8mM7CxoJpeJ46LW544WOtMbCuKbfoKH+JSCNVoqGNFHndNGSOTZtU0+BSZF5pWNCU.XfRbWX4rYvoOOajcVuZV+h5Fg44v.NauPX2fghsoNU3uKJhNHlmeGX112+dMUv8pj6esTYOexghISPkUcSAMRRasqmj1ZWRRa0IIo8jGd0SZq92Is2TIsOZsBRZqc8lzV6uJIsOUMx6bEi2OGd+721Ae+3HEquH92voFynL18G7NwqNbS+H2BA5Haz387di2sZ7jmgrZzvVRYbqzWc9zmX0eoe427V09r0+o0FOSw7wqF1R+2Uh1fy6DRR+t7m3Nm8JpIuM9cImRS6cc52L+Roi83wgUdCJbKhrGU1WR2q+tws60Qic2q22Q.P3fXBKIhmPsM74zP+C3LZhgzgVQ0BWggzsnhtLysVIxPKoqnA3Jzz6V0yEVUWXSByXyfwF6ztxl1jO7mVaaF43.ZKJX4t6m3.NFxPznlcCRnuquqnss9BGHtpt32jD6BwPGiTnoF6lCp26IydlpoeAspalqqF5ei130m79D+zoYmyliwV9xBZayNkF.ozoX7EfbXOR2.QtTybxc4Ldd+1Fv.d.UD6exITy6DJxfVWHHNcFH4Eq+.Z.kjnkm9p0UM6IsAPSluv9J232BiW+SrBtUjERp7mi96O0ez5u+MbFJT+7ONQ5WAC0zqVIMbW42+38Mw+zA2DmQHwIleTVawkELtUpDvtYoeVwr3ckigGJc5vOoKDt54HGGysZjEVcRW3RS5BWdRW3JS5BWcRWXsIcg26wuP4KCx9NDYdB7bolaq9hcK0KkRSYP+FnCqdqL

If you wrap the whole bands filters into one oversampling node, you'll consume less CPU than wrapping each band into separate OS nodes obviously, but there's not way to further decrease the CPU consumption.
Keep in mind that once the node will be compiled, it will consume less CPU that it does in the scriptnode graph.

[Straticah]

@Matt_SF interesting in my compiled build it was indeed audible, i will check your example thank you :)

[aaronventure]

It's a known bug, the oversampling messes up the filter display (by the same factor probably).

It shouldn't affect the sound (haven't checked compiled plugin). The workaround is to duplicate your filter setup in a separate node (could be a modchain node), output these filters to the same external slot, put them into a soft bypass node so that they're not actually using up your CPU and then use them for the display while using the oversampled filters for the actual processing.

Hacky, but it should work.

[Matt_SF]

@aaronventure Hacky indeed, but I confirm it works :grinning_face_with_sweat:

[Straticah]

@Matt_SF @aaronventure if its indeed just visible i might have messed up the dial linking when wrapping into an oversampling container. because in my build it was very audible and unusable.

Will do that again and double check. If its just visual i will not have a problem with that. thank you.

[orange]

@Straticah If you have Plugin Doctor app, you can also check it from there. This will give you a better understanding of whether it's affecting your sound or not.

[griffinboy]

@Straticah

Antialiasing gets complex if you want to minimise oversampling.
You have to dig into the research and develop your own filters