more specific ? i did try some switching of signs but didnt get anywhere
im starting to think it may be the coefficients, i tried it with arbitrary numbers (all 1s, all 0.5s etc) and the filter itself seems to be fine . .
MegaHurtz ·
Problem is I can recognise filters by sound,create and calculate them digitally and analog.. but i never related to filters in butterworth polynominals. To me an "optimal filter" is a LR4.
I don't have time to look at the math right now, but I can tell you just from a quick glance that your transfer function is still in the frequency domain. It needs to be transformed into the time domain to work correctly.
-cyto
ps. if you leave your "c" values rounded to such high numbers (x.xxxx), I can almost guarantee that if you do get this thing working, it will be very unstable. Use all the bits you can!
tor ·
have a look at the two pole example here:
https://ccrma.stanford.edu/~jos/fp/Direct_Form_II.html
if it is not compensated somewhere else in the coef calculations i guess the "in + b1*" should read "in - b1*"
i know some times people switch their a and b's in biquads. i have not yet read the paper you refered to so i cant tell atm in your case.
I think that the problem is maybe that SM's code component does not provide the type of DOUBLE float...
infuzion ·
kaj wrote: I think that the problem is maybe that SM's code component does not provide the type of DOUBLE float...
Did you say you were going to vote on this thread?
+ SSE2=64bit audio, SSE3=faster FFT... please
firmament ·
thanks for the help guys!
MegaHurtz wrote: Problem is I can recognise filters by sound,create and calculate them digitally and analog.. but i never related to filters in butterworth polynominals. To me an "optimal filter" is a LR4.
this uses legendre polynomials rather than butterworth ones. theres already code around for l-r filters.
cyto wrote: I don't have time to look at the math right now, but I can tell you just from a quick glance that your transfer function is still in the frequency domain. It needs to be transformed into the time domain to work correctly.
the z values are delays, its configured like this
except with another delay in. pretty sure ive translated it to time domain - mathematically i took the H(s) transfer function and use thed bilinear transform to get discrete time H(z). i read this could be used directly for filter coefficients? or do i need a laplace transform for impulse response or something
cyto wrote: ps. if you leave your "c" values rounded to such high numbers (x.xxxx), I can almost guarantee that if you do get this thing working, it will be very unstable. Use all the bits you can!
thanks haha ive fixed this. ive also corrected one of the signs in my calculations for the b coefficients (interestingly they show some sort of symmetry) and the filter corner is now at the frequency i set. the response also looks about right - however its upside down / rotated somehow . . any ideas?
firmament ·
tor wrote: have a look at the two pole example here:
https://ccrma.stanford.edu/~jos/fp/Direct_Form_II.html
if it is not compensated somewhere else in the coef calculations i guess the "in + b1*" should read "in - b1*"
i know some times people switch their a and b's in biquads. i have not yet read the paper you refered to so i cant tell atm in your case.
no idea whether this is right or not but id say its fixed cutoff and samplerate so i cant do much with it . . what cutoff frequency did you give it? i could check whether my coeffs are giving the same results . .
I think that the problem is maybe that SM's code component does not provide the type of DOUBLE float...
yeah this isnt working, sm cant seem to handle the 8.414e-16 numbers.
wait isnt there a double primitive in the toolbox? does that get full 64bit precision?
kaj ·
to firmament
Let me know the transfer function H(s) that you used.
MegaHurtz ·
1/C*F*PI2
So.. its getting integrated at the plus signs?
tor ·
firmament wrote: wait isnt there a double primitive in the toolbox? does that get full 64bit precision?
you can do plus minus and multiplication in 64 bit but you can only feed them with 32 bit values. i designed a biquad that takes advantage of this. you find it in the RBJ ported thread. though it is not truly 64bit in the whole filter due to the delay part of the scematic in 32 bit, the multiplications of the feedbacked signals results in more presicion in the bass and less rounding noise in general. problem is when you want to any thing but plus, minus & multiplication you have to use the stream2double and double2stream prims. i do belive this is not so cpu friendly and it prevent you for having a end to end 64bit design 🙁
tor ·
i made a quick 3-pole version for you to test. I have not tested it myself. But im pretty sure it should work right. Now you should also do the precalculations and coeffisient calculations in double to get even bettet results. At the cost of some more cpu of cource.
If you do coef maths in double you must delete the stream2double prims for the coefs in my scematic. but i guess you would understand that 😀
firmament ·
kaj wrote: Let me know the transfer function H(s) that you used.
see what the calculator comes up with 😉
MegaHurtz wrote: 1/C*F*PI2
So.. its getting integrated at the plus signs?
sorry not really sure what you mean here ? i have a similar part in the schematic [ tan(pi*f/sr) ] to calculate the k coefficient in the code, its to do with making the frequency setting samplerate independent
tor wrote: you can do plus minus and multiplication in 64 bit but you can only feed them with 32 bit values. i designed a biquad that takes advantage of this. you find it in the RBJ ported thread. though it is not truly 64bit in the whole filter due to the delay part of the scematic in 32 bit, the multiplications of the feedbacked signals results in more presicion in the bass and less rounding noise in general. problem is when you want to any thing but plus, minus & multiplication you have to use the stream2double and double2stream prims. i do belive this is not so cpu friendly and it prevent you for having a end to end 64bit design 🙁
I'll try and find the ported rbj thread as the example you gave me isnt loading.
the 64bit stuff seems . . useless? if you can only feed it 32 bit values then round them back off to 32 bit at the end . .
kaj ·
Hello.
***************************
prewarped freq = 2/T*tan(2*pi*freq*T/2), where T is sample time.
***************************
when cutoff freq = 5000 and T= 1/44100, then
prewarped freq = 32815.591 (which is the actual input value)
I ment that the z transform would be differentiating, given that multiplying a differentiated result would create a filter. And multiplying an integrated signal would create gain. So i wasnt able to see where it would get integrated again. Wich would be needed somewhere..
w = 2*44100 * tan1(0.5*wo/44100); // prewarping the digital freq
ww = w * w;
www = ww * w;
r = (99316848847*www+20618754192943200*ww+1753981684186662000000*w+118029161812506173712000000);
a = (297950546541*www+20618754192943200*ww-1753981684186662000000*w-354087485437518521136000000);
b = (297950546541*www-20618754192943200*ww-1753981684186662000000*w+354087485437518521136000000);
c = (99316848847*www-20618754192943200*ww+1753981684186662000000*w-118029161812506173712000000);
a = a/r;
b = b/r;
c = c/r;
d = 99316848847*www/r;
e = 297950546541*www/r;
f = 297950546541*www/r;
g = 99316848847*www/r;
firmament wrote: I'll try and find the ported rbj thread as the example you gave me isnt loading.
the 64bit stuff seems . . useless? if you can only feed it 32 bit values then round them back off to 32 bit at the end . .
ok?
lets just say that numbers with one decimal represent 32 bit and two decimal represent 64 bit
in 64 bit with conversion after calculations:
1.2*1.2+1.2*1.2=1.44+1.44=2.88≃2.9 (0.02 in diff)
in 32 bit with no conversion:
1.2*1.2+1.2*1.2=1.4+1.4=2.8 (0.08 in diff)
as you can see there is a huge difference and in a feedback structure theese errors build up quickly 😉
firmament ·
I've done a few ports of kaj's code to get them working in synthmaker. however because of precision issues, they arent accurate below ~300hz and break down completely sub-50
the explicit one is the full unoptimised code. asm optimised, it uses >20 cycles. the 64bit version is more accurate (thanks for the tip tor) but the difference isn't very significant
MegaHurtz ·
It ougta be 64 bits when it runs 64 bits 😉
tor ·
You are very welcome 🙂
Measurements I have done with the 2-pole biquads in VST Plugin Analyser shows a difference in prox -50dB for the noise floor. And in the bass area the altered frequencies sounds more clean and clear. But I totally agree that it should be possible to do all of the calculations in 64 bit. The speed of the digital revolution makes me think we soon will see plugs prosessing at 128 bit 😉
But they are probably not going to be created in SM
infuzion ·
firmament wrote: asm optimised, it uses >20 cycles.
3p Opt-L ASM2 is missing links from the green to the ASM. I assume connect in the order of the last math item?
firmament ·
infuzion wrote:
firmament wrote: asm optimised, it uses >20 cycles.
3p Opt-L ASM2 is missing links from the green to the ASM. I assume connect in the order of the last math item?
yeah, theyre arranged so the column of multiplies on the far right of the green mess are in the same descending order as the coefficient inputs of the asm.
In case anyone was dying to know, the filter is the "optimum" midpoint between chebyshev and butterworth, giving the steepest cutoff possible without ripple
MegaHurtz ·
^^ Also getting a bit steeper as it drops into infinity.
firmament ·
tor wrote: ok?
lets just say that numbers with one decimal represent 32 bit and two decimal represent 64 bit
in 64 bit with conversion after calculations:
1.2*1.2+1.2*1.2=1.44+1.44=2.88≃2.9 (0.02 in diff)
in 32 bit with no conversion:
1.2*1.2+1.2*1.2=1.4+1.4=2.8 (0.08 in diff)
as you can see there is a huge difference and in a feedback structure theese errors build up quickly 😉
haha should have thought it through before I posted really 😉 and i see how 128 bit could be useful.. not sure how to get this filter to work otherwise.
attached is a minor fix, the green stuff was missing quite a bit in the asm version so ive cleared that up
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker