hi thomas, hi list,
working with the iem filters, i experienced some control rate frequencies (48000Hz / 64 smps) while interpolating between values ...
this is basically because the filter coefficients are only changed at control rate, not at audio rate. are there any plans to change this behaviour? it would make it easier to have interpolations when changing several parameters without the need to crossfade between several filters ... on the other hand, the filters would become more expensive ... (possibly not as expensive as vcf~s)
thanks in advance ... tim
hi tim,
maybe the usage of block~ with a blocksize-argument less than 64 would help you, to find an optimum between crackle-less sound and good performance. to increase the interpolation time of the filters will improve the quality of interpolation too. the vcf-filters calculate their z-parameters every 4 samples, sin() and cos() are realized by a 2-point interpolation of a lookup table.
cheers, thomas.
Zitiere Tim Blechmann TimBlechmann@gmx.net:
hi thomas, hi list, working with the iem filters, i experienced some control rate frequencies (48000Hz / 64 smps) while interpolating between values ... this is basically because the filter coefficients are only changed at control rate, not at audio rate. are there any plans to change this behaviour? it would make it easier to have interpolations when changing several parameters without the need to crossfade between several filters ... on the other hand, the filters would become more expensive ... (possibly not as expensive as vcf~s)
maybe the usage of block~ with a blocksize-argument less than 64
well, a blocksize of 4 was enough for my ears ...
still, profiling i figured out, you are using sin/cos instead of sinf/cosf, which should be faster ... since they work with float instead of doubles ... not part of ansi c but of c99 (at least gcc supports them)...
cheers ... tim
maybe the usage of block~ with a blocksize-argument less than 64
well, a blocksize of 4 was enough for my ears ... still, profiling i figured out, you are using sin/cos instead of sinf/cosf, which should be faster ... since they work with float instead of doubles ... not part of ansi c but of c99 (at least gcc supports them)...
hm ... doing even more profiling on hml_shelf~, i'm found that the stability checking (at a blocksize of 4) is much more expensive than the actual _perform function, due to the sinf, cosf calls...
the specific part from opreport: 111961 2.3181 libm-2.3.4.so __sinf 107115 2.2177 hml_shelf~.pd_linux sighml_shelf_calc 103545 2.1438 hml_shelf~.pd_linux sighml_shelf_perform 54676 1.1320 libm-2.3.4.so __cosf
i'm not really familiar with filter design, but hot accurate does the sin/cos functions have to be? would it make sense to replace the libm functions with table lookups (like in osc~)? not sure, if it would be accurate enough, though ...
cheers ... tim
maybe the usage of block~ with a blocksize-argument less than 64
well, a blocksize of 4 was enough for my ears ...
using hml_shelf with a blocksize of blocksize of 8, the filter becomes pretty unstable ... i've attached an example patch showing this behaviour (you might have to reload it a couple of times) same parameters work fine with blocksizes of 4 and 16 ...
would be great, if you could have a look at it ...
thanks in advance ... tim
-
musil＠iem.at -
Tim Blechmann