Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-18 Thread cyrille henry



Le 18/10/2016 à 00:47, katja a écrit :

The filter recipe that Christof pointed to was easy to plug into the C
code of [hip~] and works perfectly. But when looking further in
d_filter.c I came across an approximation function 'sigbp_qcos()' used
in the bandpass filter. It made me realize once more how passionate
Miller is about efficiency. I'm not going to make a fool of myself by
submitting a 'fix' using two trig functions to calculate a filter
coefficient when a simple approximation could do the job. So that is
what I'm now looking into, with help of a math friend: an efficient
polynomial approximation for (1-sin(x))/cos(x).

according to libre office linear regression, for x between 0 and Pi, 
(1-sin(x))/cos(x) is about :
-0.057255x³ + 0.27018x² - 0.9157x + 0.99344

the calc is in attachment, if you want to tune the input source or precision.
cheers
c




Katja

On Sat, Oct 15, 2016 at 4:59 PM, katja <katjavet...@gmail.com> wrote:

Thanks for your pointers Christof. The recipe you mention from
arpchord.com is different than iemlib's, but yields identical
normalization and feedback coefficients, thus the same beautiful
response. As you say, what's in the textbooks is common knowledge and
can be used by everyone. Now I'll try to get the same result in C.

By the way, [iemlib/hp~] seems to recalculate coefficients for every
dsp vector which explains the higher CPU load.

Katja

On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at> wrote:

If iemlib's license allows to use the recipe in BSD


IMHO, the correct formular for the cutoff frequency below (which I guess is 
also used in [hp1~] since the frequency response is the same) is 'common 
knowledge', so I don't think you'd have to pay attention to any licence.



Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
Von: "Christof Ressi" <christof.re...@gmx.at>
An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
Cc: pd-list <pd-l...@iem.at>
Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?


But coefficients aren't recalculated so
often, therefore this difference will be negligible.


That's a good point. You're right that both involve a feedback and feedforward, 
so I'm wondering why [hp1~] needs more CPU... otherwise, iemlib's filters are 
very efficient.

Anyway, I researched a bit and found the reason why the frequency response of 
Pd filters seems 'wrong':

Miller uses a formular for calculating the cutoff frequency which is taken from 
analog filters but is not really adequate for digital filters since it doesn't 
reflect the cyclic nature of the digital domain (although you can see it in 
some articles on digital filters).

Let's take [hip~] as an example:

the formular for a 1-pole 1-zero highpass goes:
y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]

Miller calculates the position of the pole with
k = 1 - (fc * 2*pi / SR).

The correct formular, however (if you want the frequency response to be zero at 
Nyquist!), would be
k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.

You can find it here: 
http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf

BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
clips the coefficient below 0, so it never reaches -1 (where the gain would be 
all zero).

Also, there is another approximation with a similiar behaviour, which goes like 
this:
k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.

Now, is the behaviour of [hip~] 'wrong'?
If you define at 1-pole 1-zero high pass filter as something which passes 
everything at fc = DC and blocks everything at fc = Nyquist, then I'd say yes.
If it should roughly model an analogue filter (where the cutoff frequency can 
go up to infinity) for low cutoff frequencies only, then I'd say no.

Also, as I tried to point out, this issue with the cutoff frequency is true for 
all Pd filters!

So I think this behaviour should either be changed (great, if Katja is willing 
to submit a patch!) or documented in the help patch (gain is not 0 at Nyquist!).

I'm not an engineer or any expert on filter design. It's just my two cents :-)

Christof






Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
Von: katja <katjavet...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: pd-list <pd-l...@iem.at>
Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

I'm pretty confident [hip~] would not loose its efficiency when using
iemlib's recipe. Both hi pass filters have a feed forward and feedback
component, with coefficients for normalization and feedback.
Calculation of these coefficients is a bit more involved with iemlib's
recipe, using trig functions. But coefficients aren't recalculated so
often, therefore this difference will be negligible.

To reassure, it is not my intention to spark

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread Ivica Ico Bukvic

Cool, thank you.


On 10/17/2016 12:36 PM, cyrille henry wrote:
It was updated for 0.44, so it's not a correction of the bug Katja 
pointed (in the 0.47)


The updated is describe in hip~ help file as follow :

COMPATIBILITY NOTE: in Pd versions before 0.44, the high-frequency 
output gain was incorrectly greater than one (usually only slightly 
so, but noticeably if the cutoff frequency was more than 1/4 the 
Nyquist frequency). This problem was fixed INCORECTLY in pd 0.44-0 
thoguh 0.44-2, and is now hopefully fixed since Pd 0.44-3. To get the 
old (0.43 and earlier) behavior, set "compatibility" to 0.43 in Pd's 
command line or by a message:


I think more information can be found in this mailing list archive.

I just wanted to point that this filter can be update while keeping 
compatibility with old patch (since it already have been done few 
years ago).


cheers
c

Le 17/10/2016 à 18:06, Ivica Ico Bukvic a écrit :

On 10/17/2016 8:47 AM, cyrille henry wrote:
they have been recently updated (0.44). Many patchs rely on the old 
sound they deliver, this is achieved via the compatibility flag.

(see help file).


Updated as in fixed the bugs pointed out here or if not, what was 
updated in them?


Best,

Ico


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread katja
The filter recipe that Christof pointed to was easy to plug into the C
code of [hip~] and works perfectly. But when looking further in
d_filter.c I came across an approximation function 'sigbp_qcos()' used
in the bandpass filter. It made me realize once more how passionate
Miller is about efficiency. I'm not going to make a fool of myself by
submitting a 'fix' using two trig functions to calculate a filter
coefficient when a simple approximation could do the job. So that is
what I'm now looking into, with help of a math friend: an efficient
polynomial approximation for (1-sin(x))/cos(x).

Katja

On Sat, Oct 15, 2016 at 4:59 PM, katja <katjavet...@gmail.com> wrote:
> Thanks for your pointers Christof. The recipe you mention from
> arpchord.com is different than iemlib's, but yields identical
> normalization and feedback coefficients, thus the same beautiful
> response. As you say, what's in the textbooks is common knowledge and
> can be used by everyone. Now I'll try to get the same result in C.
>
> By the way, [iemlib/hp~] seems to recalculate coefficients for every
> dsp vector which explains the higher CPU load.
>
> Katja
>
> On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at> wrote:
>>> If iemlib's license allows to use the recipe in BSD
>>
>> IMHO, the correct formular for the cutoff frequency below (which I guess is 
>> also used in [hp1~] since the frequency response is the same) is 'common 
>> knowledge', so I don't think you'd have to pay attention to any licence.
>>
>>
>>> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
>>> Von: "Christof Ressi" <christof.re...@gmx.at>
>>> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
>>> Cc: pd-list <pd-l...@iem.at>
>>> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>>
>>> > But coefficients aren't recalculated so
>>> > often, therefore this difference will be negligible.
>>>
>>> That's a good point. You're right that both involve a feedback and 
>>> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, 
>>> iemlib's filters are very efficient.
>>>
>>> Anyway, I researched a bit and found the reason why the frequency response 
>>> of Pd filters seems 'wrong':
>>>
>>> Miller uses a formular for calculating the cutoff frequency which is taken 
>>> from analog filters but is not really adequate for digital filters since it 
>>> doesn't reflect the cyclic nature of the digital domain (although you can 
>>> see it in some articles on digital filters).
>>>
>>> Let's take [hip~] as an example:
>>>
>>> the formular for a 1-pole 1-zero highpass goes:
>>> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
>>>
>>> Miller calculates the position of the pole with
>>> k = 1 - (fc * 2*pi / SR).
>>>
>>> The correct formular, however (if you want the frequency response to be 
>>> zero at Nyquist!), would be
>>> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
>>>
>>> You can find it here: 
>>> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>>>
>>> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
>>> clips the coefficient below 0, so it never reaches -1 (where the gain would 
>>> be all zero).
>>>
>>> Also, there is another approximation with a similiar behaviour, which goes 
>>> like this:
>>> k = e^(-2*pi*fc/SR). I could find it here: 
>>> http://www.dspguide.com/ch19/2.htm
>>> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.
>>>
>>> Now, is the behaviour of [hip~] 'wrong'?
>>> If you define at 1-pole 1-zero high pass filter as something which passes 
>>> everything at fc = DC and blocks everything at fc = Nyquist, then I'd say 
>>> yes.
>>> If it should roughly model an analogue filter (where the cutoff frequency 
>>> can go up to infinity) for low cutoff frequencies only, then I'd say no.
>>>
>>> Also, as I tried to point out, this issue with the cutoff frequency is true 
>>> for all Pd filters!
>>>
>>> So I think this behaviour should either be changed (great, if Katja is 
>>> willing to submit a patch!) or documented in the help patch (gain is not 0 
>>> at Nyquist!).
>>>
>>> I'm not an engineer or any expert on filter design. It's just my two cents 
>>> :-)
>>>
>>> Christof
>>>
>>>
>>&

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread cyrille henry

It was updated for 0.44, so it's not a correction of the bug Katja pointed (in 
the 0.47)

The updated is describe in hip~ help file as follow :

COMPATIBILITY NOTE: in Pd versions before 0.44, the high-frequency output gain was 
incorrectly greater than one (usually only slightly so, but noticeably if the cutoff 
frequency was more than 1/4 the Nyquist frequency). This problem was fixed INCORECTLY in 
pd 0.44-0 thoguh 0.44-2, and is now hopefully fixed since Pd 0.44-3. To get the old (0.43 
and earlier) behavior, set "compatibility" to 0.43 in Pd's command line or by a 
message:

I think more information can be found in this mailing list archive.

I just wanted to point that this filter can be update while keeping 
compatibility with old patch (since it already have been done few years ago).

cheers
c

Le 17/10/2016 à 18:06, Ivica Ico Bukvic a écrit :

On 10/17/2016 8:47 AM, cyrille henry wrote:

they have been recently updated (0.44). Many patchs rely on the old sound they 
deliver, this is achieved via the compatibility flag.
(see help file).


Updated as in fixed the bugs pointed out here or if not, what was updated in 
them?

Best,

Ico


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread Ivica Ico Bukvic

On 10/17/2016 8:47 AM, cyrille henry wrote:
they have been recently updated (0.44). Many patchs rely on the old 
sound they deliver, this is achieved via the compatibility flag.

(see help file).


Updated as in fixed the bugs pointed out here or if not, what was 
updated in them?


Best,

Ico


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread cyrille henry



Le 17/10/2016 à 14:17, i go bananas a écrit :

as imperfect as Vanilla's lop~ / hip~ / vcf~ objects may be...i would strongly 
argue against replacing them in the same namespace, as many old patches rely on 
the sound they deliver.



they have been recently updated (0.44). Many patchs rely on the old sound they 
deliver, this is achieved via the compatibility flag.
(see help file).

cheers
c




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread i go bananas
as imperfect as Vanilla's lop~ / hip~ / vcf~ objects may be...i would
strongly argue against replacing them in the same namespace, as many old
patches rely on the sound they deliver.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread Christof Ressi
Thanks for the paper! I couldn't find [mvcf~] in the ekext deken package but 
there is a [lpreson~], are these somehow related? Anyway, I will compile 
[mvcf~] from source and listen to it :-).
 
 

Gesendet: Montag, 17. Oktober 2016 um 12:49 Uhr
Von: "Ed Kelly" <morph_2...@yahoo.co.uk>
An: "Alexandre Torres Porres" <por...@gmail.com>, "Christof Ressi" 
<christof.re...@gmx.at>
Cc: pd-list <pd-l...@iem.at>
Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

Hey people,
 
While I'm not an expert with digital filters, I did manage to piece together a 
decent-sounding ladder emulation instead of vcf~ a while ago. It only does 
resonant lowpass though. It's called mvcf~ and is found in the ekext externals 
library.
 
I've since been reading about analogue filter design and I reckon there may be 
high pass and band pass filters available from the source code, with the 
correct adjustment to the algorithm.
 
 

I'm trying to work out how to adjust the coefficients to accurately model the 
alternative functions (i.e. highpass, and hence bandpass through arithmetic 
processes) according to the resistance factors outlined in this paper. Any help 
would be appreciated :)
 
So, currently, at line 78 in the code I have translations for highpass and 
bandpass (the current implementation is lowpass only with a gain factor) but I 
may be stupid in not trying this myself (or I've just been super-busy with 
other stuff - I'm marking this week). The idea of implementing the other two 
modes comes from an Electronotes paper from Bernie Hutchins in the 1970s. 
http://electronotes.netfirms.com/EN85VCF.PDF
 
Take a look.
Cheers,
Ed
 
PS have yet to try bob~ but it sounds interesting...will check it out.
 
 
 
 

 

On Sunday, 16 October 2016, 13:10, Alexandre Torres Porres <por...@gmail.com> 
wrote: 

> But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced
> by better filters in the future (while keeping the old ones for compatibility 
> reasons).
 
how about bob~?
 

2016-10-14 21:34 GMT-03:00 Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:There are a number of big 
problems with all build-in filters in Pd (expect for the raw filters).

Problem number 1:
[lop~] and [hip~] both use a weird (you could also say: wrong) formula for the 
cutoff frequency which makes them gradually converge to a fixed output state 
(reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. 
Therefore the actual cutoff frequency is only correct for very low frequencies 
and approximately gets more and more off until it doesn't move at all.

Problem number 2:
[bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
slope is different for each side and changes with frequency.

Problem number 3:
the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather 
depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!

I did some FFT plots, see the attachment.

I remember Miller saying somewhere that these filters are not designed for high 
cutoff frequencies - but even for low frequencies, the behaviour of [bp~] and 
[vcf~] is horrible. I can see these filters are mere approximations to reduce 
CPU usage.
[hip~] is indeed much more efficient than iemlib's [hp1~], so it's well suited 
for DC removal (but not much else).
[bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
latter one has a correct and stable frequency response.
[vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my 
laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to 
consider that [vcf_bp2~] not only acts correctly but lets you set the Q at 
audio rate. The high CPU usage of [vcf~] seems like a bug to me...

I only use the vanilla filters for the most basic stuff like DC removal and 
smoothing. I guess these are the use cases which Miller had in mind and that 
way [lop~] and [hip~] have their justification (although there should be some 
more warning about the 'wrong' frequency response in the help file).
But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced 
by better filters in the future (while keeping the old ones for compatibility 
reasons).

Christof


> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
> Von: katja <katjavet...@gmail.com[mailto:katjavet...@gmail.com]>
> An: pd-list <pd-l...@iem.at[mailto:pd-l...@iem.at]>
> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?

>
> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
> -3 dB at cutoff consistently.
>
> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
> if the license also 

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-17 Thread Ed Kelly via Pd-list
Hey people,
While I'm not an expert with digital filters, I did manage to piece together a 
decent-sounding ladder emulation instead of vcf~ a while ago. It only does 
resonant lowpass though. It's called mvcf~ and is found in the ekext externals 
library.
I've since been reading about analogue filter design and I reckon there may be 
high pass and band pass filters available from the source code, with the 
correct adjustment to the algorithm. I'm trying to work out how to adjust the 
coefficients to accurately model the alternative functions (i.e. highpass, and 
hence bandpass through arithmetic processes) according to the resistance 
factors outlined in this paper. Any help would be appreciated :)
So, currently, at line 78 in the code I have translations for highpass and 
bandpass (the current implementation is lowpass only with a gain factor) but I 
may be stupid in not trying this myself (or I've just been super-busy with 
other stuff - I'm marking this week). The idea of implementing the other two 
modes comes from an Electronotes paper from Bernie Hutchins in the 1970s. 
http://electronotes.netfirms.com/EN85VCF.PDF

Take a look.Cheers,Ed
PS have yet to try bob~ but it sounds interesting...will check it out. 
 

   

 On Sunday, 16 October 2016, 13:10, Alexandre Torres Porres  
wrote:
 
 

 > But [bp~] and [vcf~] are almost unusable IMHO and should probably be 
 >replaced> by better filters in the future (while keeping the old ones for 
 >compatibility reasons).

how about bob~?
2016-10-14 21:34 GMT-03:00 Christof Ressi :

There are a number of big problems with all build-in filters in Pd (expect for 
the raw filters).

Problem number 1:
[lop~] and [hip~] both use a weird (you could also say: wrong) formula for the 
cutoff frequency which makes them gradually converge to a fixed output state 
(reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. 
Therefore the actual cutoff frequency is only correct for very low frequencies 
and approximately gets more and more off until it doesn't move at all.

Problem number 2:
[bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
slope is different for each side and changes with frequency.

Problem number 3:
the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather 
depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!

I did some FFT plots, see the attachment.

I remember Miller saying somewhere that these filters are not designed for high 
cutoff frequencies - but even for low frequencies, the behaviour of [bp~] and 
[vcf~] is horrible. I can see these filters are mere approximations to reduce 
CPU usage.
[hip~] is indeed much more efficient than iemlib's [hp1~], so it's well suited 
for DC removal (but not much else).
[bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
latter one has a correct and stable frequency response.
[vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my 
laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to 
consider that [vcf_bp2~] not only acts correctly but lets you set the Q at 
audio rate. The high CPU usage of [vcf~] seems like a bug to me...

I only use the vanilla filters for the most basic stuff like DC removal and 
smoothing. I guess these are the use cases which Miller had in mind and that 
way [lop~] and [hip~] have their justification (although there should be some 
more warning about the 'wrong' frequency response in the help file).
But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced 
by better filters in the future (while keeping the old ones for compatibility 
reasons).

Christof


> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
> Von: katja 
> An: pd-list 
> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>
> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
> -3 dB at cutoff consistently.
>
> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
> if the license also covers the math. Documentation in
> https://git.iem.at/pd/iemlib/ tree/master points to external literature
> for part of the math (bilinear transform). I've implemented the recipe
> with vanilla objects for comparison, see attached.
>
> Katja
> __ _
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
> listinfo/pd-list
> 
__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management 

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-16 Thread Christof Ressi
> well, it's got 2 (different) outputs, so it's like 2 filters in there

[vcf~] is one filter, it just outputs both the real and imaginary part (which 
have to be computed anyway), so the idea is you get two filters for the price 
of one. I have no idea what causes the relatively high CPU load. maybe the 
tabfudge stuff? 

> how about bob~?
 
[bob~] is cool, but it's a bit expensive. Moreover, it's not a bandpass ;-) 

Gesendet: Sonntag, 16. Oktober 2016 um 13:39 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: katja <katjavet...@gmail.com>, pd-list <pd-l...@iem.at>
Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

> But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced
> by better filters in the future (while keeping the old ones for compatibility 
> reasons).
 
how about bob~?
 
2016-10-14 21:34 GMT-03:00 Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:There are a number of big 
problems with all build-in filters in Pd (expect for the raw filters).

Problem number 1:
[lop~] and [hip~] both use a weird (you could also say: wrong) formula for the 
cutoff frequency which makes them gradually converge to a fixed output state 
(reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. 
Therefore the actual cutoff frequency is only correct for very low frequencies 
and approximately gets more and more off until it doesn't move at all.

Problem number 2:
[bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
slope is different for each side and changes with frequency.

Problem number 3:
the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather 
depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!

I did some FFT plots, see the attachment.

I remember Miller saying somewhere that these filters are not designed for high 
cutoff frequencies - but even for low frequencies, the behaviour of [bp~] and 
[vcf~] is horrible. I can see these filters are mere approximations to reduce 
CPU usage.
[hip~] is indeed much more efficient than iemlib's [hp1~], so it's well suited 
for DC removal (but not much else).
[bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
latter one has a correct and stable frequency response.
[vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my 
laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to 
consider that [vcf_bp2~] not only acts correctly but lets you set the Q at 
audio rate. The high CPU usage of [vcf~] seems like a bug to me...

I only use the vanilla filters for the most basic stuff like DC removal and 
smoothing. I guess these are the use cases which Miller had in mind and that 
way [lop~] and [hip~] have their justification (although there should be some 
more warning about the 'wrong' frequency response in the help file).
But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced 
by better filters in the future (while keeping the old ones for compatibility 
reasons).

Christof


> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
> Von: katja <katjavet...@gmail.com[mailto:katjavet...@gmail.com]>
> An: pd-list <pd-l...@iem.at[mailto:pd-l...@iem.at]>
> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?

>
> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
> -3 dB at cutoff consistently.
>
> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
> if the license also covers the math. Documentation in
> https://git.iem.at/pd/iemlib/tree/master[https://git.iem.at/pd/iemlib/tree/master]
>  points to external literature
> for part of the math (bilinear transform). I've implemented the recipe
> with vanilla objects for comparison, see attached.
>
> Katja> ___
> Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>
___
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-16 Thread Alexandre Torres Porres
> But [bp~] and [vcf~] are almost unusable IMHO and should probably be
replaced
> by better filters in the future (while keeping the old ones for
compatibility reasons).

how about bob~?

2016-10-14 21:34 GMT-03:00 Christof Ressi :

> There are a number of big problems with all build-in filters in Pd (expect
> for the raw filters).
>
> Problem number 1:
> [lop~] and [hip~] both use a weird (you could also say: wrong) formula for
> the cutoff frequency which makes them gradually converge to a fixed output
> state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~]
> with Q <= 1. Therefore the actual cutoff frequency is only correct for very
> low frequencies and approximately gets more and more off until it doesn't
> move at all.
>
> Problem number 2:
> [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the
> slope is different for each side and changes with frequency.
>
> Problem number 3:
> the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It
> rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <=
> 1!
>
> I did some FFT plots, see the attachment.
>
> I remember Miller saying somewhere that these filters are not designed for
> high cutoff frequencies - but even for low frequencies, the behaviour of
> [bp~] and [vcf~] is horrible. I can see these filters are mere
> approximations to reduce CPU usage.
> [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well
> suited for DC removal (but not much else).
> [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but
> the latter one has a correct and stable frequency response.
> [vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on
> my laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have
> to consider that [vcf_bp2~] not only acts correctly but lets you set the Q
> at audio rate. The high CPU usage of [vcf~] seems like a bug to me...
>
> I only use the vanilla filters for the most basic stuff like DC removal
> and smoothing. I guess these are the use cases which Miller had in mind and
> that way [lop~] and [hip~] have their justification (although there should
> be some more warning about the 'wrong' frequency response in the help file).
> But [bp~] and [vcf~] are almost unusable IMHO and should probably be
> replaced by better filters in the future (while keeping the old ones for
> compatibility reasons).
>
> Christof
>
>
> > Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
> > Von: katja 
> > An: pd-list 
> > Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
> >
> > In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
> > constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
> > cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
> > -3 dB at cutoff consistently.
> >
> > Could vanilla pd implement iemlib's hipass filter recipe? I don't know
> > if the license also covers the math. Documentation in
> > https://git.iem.at/pd/iemlib/tree/master points to external literature
> > for part of the math (bilinear transform). I've implemented the recipe
> > with vanilla objects for comparison, see attached.
> >
> > Katja
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-16 Thread Alexandre Torres Porres
> The high CPU usage of [vcf~] seems like a bug to me...

well, it's got 2 (different) outputs, so it's like 2 filters in there,
hence twice the CPU consumption maybe? I dont know vcf~ from iemlib...

2016-10-14 21:34 GMT-03:00 Christof Ressi :

> There are a number of big problems with all build-in filters in Pd (expect
> for the raw filters).
>
> Problem number 1:
> [lop~] and [hip~] both use a weird (you could also say: wrong) formula for
> the cutoff frequency which makes them gradually converge to a fixed output
> state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~]
> with Q <= 1. Therefore the actual cutoff frequency is only correct for very
> low frequencies and approximately gets more and more off until it doesn't
> move at all.
>
> Problem number 2:
> [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the
> slope is different for each side and changes with frequency.
>
> Problem number 3:
> the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It
> rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <=
> 1!
>
> I did some FFT plots, see the attachment.
>
> I remember Miller saying somewhere that these filters are not designed for
> high cutoff frequencies - but even for low frequencies, the behaviour of
> [bp~] and [vcf~] is horrible. I can see these filters are mere
> approximations to reduce CPU usage.
> [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well
> suited for DC removal (but not much else).
> [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but
> the latter one has a correct and stable frequency response.
> [vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on
> my laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have
> to consider that [vcf_bp2~] not only acts correctly but lets you set the Q
> at audio rate. The high CPU usage of [vcf~] seems like a bug to me...
>
> I only use the vanilla filters for the most basic stuff like DC removal
> and smoothing. I guess these are the use cases which Miller had in mind and
> that way [lop~] and [hip~] have their justification (although there should
> be some more warning about the 'wrong' frequency response in the help file).
> But [bp~] and [vcf~] are almost unusable IMHO and should probably be
> replaced by better filters in the future (while keeping the old ones for
> compatibility reasons).
>
> Christof
>
>
> > Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
> > Von: katja 
> > An: pd-list 
> > Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
> >
> > In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
> > constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
> > cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
> > -3 dB at cutoff consistently.
> >
> > Could vanilla pd implement iemlib's hipass filter recipe? I don't know
> > if the license also covers the math. Documentation in
> > https://git.iem.at/pd/iemlib/tree/master points to external literature
> > for part of the math (bilinear transform). I've implemented the recipe
> > with vanilla objects for comparison, see attached.
> >
> > Katja
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread Ed Kelly via Pd-list
PS - I normally use cyclone/svf~ in my objects, but there is a good argument 
for a decent state-variable filter included in vanilla I think.Ed
 


On Sunday, 16 October 2016, 4:52, Ed Kelly <morph_2...@yahoo.co.uk> wrote:
 
 

 Hey people,
While I'm not an expert with digital filters, I did manage to piece together a 
decent-sounding ladder emulation instead of vcf~ a while ago. It only does 
resonant lowpass though. It's called mvcf~ and is found in the ekext externals 
library.
I've since been reading about analogue filter design and I reckon there may be 
high pass and band pass filters available from the source code, with the 
correct adjustment to the algorithm. I'm trying to work out how to adjust the 
coefficients to accurately model the alternative functions (i.e. highpass, and 
hence bandpass through arithmetic processes) according to the resistance 
factors outlined in this paper. Any help would be appreciated :)
So, currently, at line 78 in the code I have translations for highpass and 
bandpass (the current implementation is lowpass only with a gain factor) but I 
may be stupid in not trying this myself (or I've just been super-busy with 
other stuff!). The idea of implementing the other two modes comes from an 
Electronotes paper from Bernie Hutchins in the 1970s. This doesn't seem to be 
free online any more, but I've enclosed it.
Take a look.Cheers,Ed



Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build 
Your Wings on the Way Down, the new digital album available @ 
http://scifirecords.co.uk/releases 
Earthlings compilation is out now @ http://www.pyramidtransmissions.com

Ninja Jamm - the revolutionary music remix app for iOS and Android: 
http://www.ninjajamm.com/

Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live 
composition and improvisation suite, available at 
http://sharktracks.co.uk/html/software.html 

   

 On Saturday, 15 October 2016, 22:10, Julian Brooks <jbee...@gmail.com> wrote:
 
 

 And my learning for the day is done.

Thanks both

On 15 October 2016 at 15:59, katja <katjavet...@gmail.com> wrote:

Thanks for your pointers Christof. The recipe you mention from
arpchord.com is different than iemlib's, but yields identical
normalization and feedback coefficients, thus the same beautiful
response. As you say, what's in the textbooks is common knowledge and
can be used by everyone. Now I'll try to get the same result in C.

By the way, [iemlib/hp~] seems to recalculate coefficients for every
dsp vector which explains the higher CPU load.

Katja

On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at> wrote:
>> If iemlib's license allows to use the recipe in BSD
>
> IMHO, the correct formular for the cutoff frequency below (which I guess is 
> also used in [hp1~] since the frequency response is the same) is 'common 
> knowledge', so I don't think you'd have to pay attention to any licence.
>
>
>> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
>> Von: "Christof Ressi" <christof.re...@gmx.at>
>> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
>> Cc: pd-list <pd-l...@iem.at>
>> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>
>> > But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>>
>> That's a good point. You're right that both involve a feedback and 
>> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, 
>> iemlib's filters are very efficient.
>>
>> Anyway, I researched a bit and found the reason why the frequency response 
>> of Pd filters seems 'wrong':
>>
>> Miller uses a formular for calculating the cutoff frequency which is taken 
>> from analog filters but is not really adequate for digital filters since it 
>> doesn't reflect the cyclic nature of the digital domain (although you can 
>> see it in some articles on digital filters).
>>
>> Let's take [hip~] as an example:
>>
>> the formular for a 1-pole 1-zero highpass goes:
>> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
>>
>> Miller calculates the position of the pole with
>> k = 1 - (fc * 2*pi / SR).
>>
>> The correct formular, however (if you want the frequency response to be zero 
>> at Nyquist!), would be
>> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
>>
>> You can find it here: http://www.arpchord.com/pdf/ 
>> coeffs_first_order_filters_ 0p1.pdf
>>
>> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
>> clips the coefficient below 0, so it never reaches -1 (where the gain would 
>> be all zero).
>>
>> Also, there is another approximation with a similiar be

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread Julian Brooks
And my learning for the day is done.

Thanks both

On 15 October 2016 at 15:59, katja <katjavet...@gmail.com> wrote:

> Thanks for your pointers Christof. The recipe you mention from
> arpchord.com is different than iemlib's, but yields identical
> normalization and feedback coefficients, thus the same beautiful
> response. As you say, what's in the textbooks is common knowledge and
> can be used by everyone. Now I'll try to get the same result in C.
>
> By the way, [iemlib/hp~] seems to recalculate coefficients for every
> dsp vector which explains the higher CPU load.
>
> Katja
>
> On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at>
> wrote:
> >> If iemlib's license allows to use the recipe in BSD
> >
> > IMHO, the correct formular for the cutoff frequency below (which I guess
> is also used in [hp1~] since the frequency response is the same) is 'common
> knowledge', so I don't think you'd have to pay attention to any licence.
> >
> >
> >> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
> >> Von: "Christof Ressi" <christof.re...@gmx.at>
> >> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
> >> Cc: pd-list <pd-l...@iem.at>
> >> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
> >>
> >> > But coefficients aren't recalculated so
> >> > often, therefore this difference will be negligible.
> >>
> >> That's a good point. You're right that both involve a feedback and
> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise,
> iemlib's filters are very efficient.
> >>
> >> Anyway, I researched a bit and found the reason why the frequency
> response of Pd filters seems 'wrong':
> >>
> >> Miller uses a formular for calculating the cutoff frequency which is
> taken from analog filters but is not really adequate for digital filters
> since it doesn't reflect the cyclic nature of the digital domain (although
> you can see it in some articles on digital filters).
> >>
> >> Let's take [hip~] as an example:
> >>
> >> the formular for a 1-pole 1-zero highpass goes:
> >> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
> >>
> >> Miller calculates the position of the pole with
> >> k = 1 - (fc * 2*pi / SR).
> >>
> >> The correct formular, however (if you want the frequency response to be
> zero at Nyquist!), would be
> >> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
> >>
> >> You can find it here: http://www.arpchord.com/pdf/
> coeffs_first_order_filters_0p1.pdf
> >>
> >> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because
> Miller clips the coefficient below 0, so it never reaches -1 (where the
> gain would be all zero).
> >>
> >> Also, there is another approximation with a similiar behaviour, which
> goes like this:
> >> k = e^(-2*pi*fc/SR). I could find it here:
> http://www.dspguide.com/ch19/2.htm
> >> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as
> well.
> >>
> >> Now, is the behaviour of [hip~] 'wrong'?
> >> If you define at 1-pole 1-zero high pass filter as something which
> passes everything at fc = DC and blocks everything at fc = Nyquist, then
> I'd say yes.
> >> If it should roughly model an analogue filter (where the cutoff
> frequency can go up to infinity) for low cutoff frequencies only, then I'd
> say no.
> >>
> >> Also, as I tried to point out, this issue with the cutoff frequency is
> true for all Pd filters!
> >>
> >> So I think this behaviour should either be changed (great, if Katja is
> willing to submit a patch!) or documented in the help patch (gain is not 0
> at Nyquist!).
> >>
> >> I'm not an engineer or any expert on filter design. It's just my two
> cents :-)
> >>
> >> Christof
> >>
> >>
> >>
> >>
> >>
> >> > Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
> >> > Von: katja <katjavet...@gmail.com>
> >> > An: "Christof Ressi" <christof.re...@gmx.at>
> >> > Cc: pd-list <pd-l...@iem.at>
> >> > Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
> >> >
> >> > I'm pretty confident [hip~] would not loose its efficiency when using
> >> > iemlib's recipe. Both hi pass filters have a feed forward and feedback
> >> > component, with coefficients for normalization and feedback.
> &g

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread katja
Thanks for your pointers Christof. The recipe you mention from
arpchord.com is different than iemlib's, but yields identical
normalization and feedback coefficients, thus the same beautiful
response. As you say, what's in the textbooks is common knowledge and
can be used by everyone. Now I'll try to get the same result in C.

By the way, [iemlib/hp~] seems to recalculate coefficients for every
dsp vector which explains the higher CPU load.

Katja

On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at> wrote:
>> If iemlib's license allows to use the recipe in BSD
>
> IMHO, the correct formular for the cutoff frequency below (which I guess is 
> also used in [hp1~] since the frequency response is the same) is 'common 
> knowledge', so I don't think you'd have to pay attention to any licence.
>
>
>> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
>> Von: "Christof Ressi" <christof.re...@gmx.at>
>> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
>> Cc: pd-list <pd-l...@iem.at>
>> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>
>> > But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>>
>> That's a good point. You're right that both involve a feedback and 
>> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, 
>> iemlib's filters are very efficient.
>>
>> Anyway, I researched a bit and found the reason why the frequency response 
>> of Pd filters seems 'wrong':
>>
>> Miller uses a formular for calculating the cutoff frequency which is taken 
>> from analog filters but is not really adequate for digital filters since it 
>> doesn't reflect the cyclic nature of the digital domain (although you can 
>> see it in some articles on digital filters).
>>
>> Let's take [hip~] as an example:
>>
>> the formular for a 1-pole 1-zero highpass goes:
>> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
>>
>> Miller calculates the position of the pole with
>> k = 1 - (fc * 2*pi / SR).
>>
>> The correct formular, however (if you want the frequency response to be zero 
>> at Nyquist!), would be
>> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
>>
>> You can find it here: 
>> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>>
>> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
>> clips the coefficient below 0, so it never reaches -1 (where the gain would 
>> be all zero).
>>
>> Also, there is another approximation with a similiar behaviour, which goes 
>> like this:
>> k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
>> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.
>>
>> Now, is the behaviour of [hip~] 'wrong'?
>> If you define at 1-pole 1-zero high pass filter as something which passes 
>> everything at fc = DC and blocks everything at fc = Nyquist, then I'd say 
>> yes.
>> If it should roughly model an analogue filter (where the cutoff frequency 
>> can go up to infinity) for low cutoff frequencies only, then I'd say no.
>>
>> Also, as I tried to point out, this issue with the cutoff frequency is true 
>> for all Pd filters!
>>
>> So I think this behaviour should either be changed (great, if Katja is 
>> willing to submit a patch!) or documented in the help patch (gain is not 0 
>> at Nyquist!).
>>
>> I'm not an engineer or any expert on filter design. It's just my two cents 
>> :-)
>>
>> Christof
>>
>>
>>
>>
>>
>> > Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
>> > Von: katja <katjavet...@gmail.com>
>> > An: "Christof Ressi" <christof.re...@gmx.at>
>> > Cc: pd-list <pd-l...@iem.at>
>> > Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>> >
>> > I'm pretty confident [hip~] would not loose its efficiency when using
>> > iemlib's recipe. Both hi pass filters have a feed forward and feedback
>> > component, with coefficients for normalization and feedback.
>> > Calculation of these coefficients is a bit more involved with iemlib's
>> > recipe, using trig functions. But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>> >
>> > To reassure, it is not my intention to spark another 'what's wrong
>> > with pd' thread. If iemlib's license allows to use the recipe in BSD
>> > code

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread Ivica Ico Bukvic

Jumping in on this thread:

If anyone who can tackle improvements on these filters can provide a 
patch for lop~, hip~, bp~ and vcf~, please copy me when submitting the 
patch, so that I can merge it with pd-l2ork. Thank you.


Best,

Ico


On 10/15/2016 7:59 AM, Christof Ressi wrote:

If iemlib's license allows to use the recipe in BSD

IMHO, the correct formular for the cutoff frequency below (which I guess is 
also used in [hp1~] since the frequency response is the same) is 'common 
knowledge', so I don't think you'd have to pay attention to any licence.



Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
Von: "Christof Ressi" <christof.re...@gmx.at>
An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
Cc: pd-list <pd-l...@iem.at>
Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?


But coefficients aren't recalculated so
often, therefore this difference will be negligible.

That's a good point. You're right that both involve a feedback and feedforward, 
so I'm wondering why [hp1~] needs more CPU... otherwise, iemlib's filters are 
very efficient.

Anyway, I researched a bit and found the reason why the frequency response of 
Pd filters seems 'wrong':

Miller uses a formular for calculating the cutoff frequency which is taken from 
analog filters but is not really adequate for digital filters since it doesn't 
reflect the cyclic nature of the digital domain (although you can see it in 
some articles on digital filters).

Let's take [hip~] as an example:

the formular for a 1-pole 1-zero highpass goes:
y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]

Miller calculates the position of the pole with
k = 1 - (fc * 2*pi / SR).

The correct formular, however (if you want the frequency response to be zero at 
Nyquist!), would be
k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.

You can find it here: 
http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf

BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
clips the coefficient below 0, so it never reaches -1 (where the gain would be 
all zero).

Also, there is another approximation with a similiar behaviour, which goes like 
this:
k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.

Now, is the behaviour of [hip~] 'wrong'?
If you define at 1-pole 1-zero high pass filter as something which passes 
everything at fc = DC and blocks everything at fc = Nyquist, then I'd say yes.
If it should roughly model an analogue filter (where the cutoff frequency can 
go up to infinity) for low cutoff frequencies only, then I'd say no.

Also, as I tried to point out, this issue with the cutoff frequency is true for 
all Pd filters!

So I think this behaviour should either be changed (great, if Katja is willing 
to submit a patch!) or documented in the help patch (gain is not 0 at Nyquist!).

I'm not an engineer or any expert on filter design. It's just my two cents :-)

Christof






Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
Von: katja <katjavet...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: pd-list <pd-l...@iem.at>
Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

I'm pretty confident [hip~] would not loose its efficiency when using
iemlib's recipe. Both hi pass filters have a feed forward and feedback
component, with coefficients for normalization and feedback.
Calculation of these coefficients is a bit more involved with iemlib's
recipe, using trig functions. But coefficients aren't recalculated so
often, therefore this difference will be negligible.

To reassure, it is not my intention to spark another 'what's wrong
with pd' thread. If iemlib's license allows to use the recipe in BSD
code I'll try patch the C of [hip~] and submit on the tracker for
review. Who knows, it may be a no-brainer.

Katja





On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi <christof.re...@gmx.at> wrote:

There are a number of big problems with all build-in filters in Pd (expect for 
the raw filters).

Problem number 1:
[lop~] and [hip~] both use a weird (you could also say: wrong) formula for the 
cutoff frequency which makes them gradually converge to a fixed output state 
(reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. 
Therefore the actual cutoff frequency is only correct for very low frequencies and 
approximately gets more and more off until it doesn't move at all.

Problem number 2:
[bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
slope is different for each side and changes with frequency.

Problem number 3:
the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather 
depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!

I did some FFT plots, see the attachment.

I remember Miller saying s

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread Christof Ressi
> If iemlib's license allows to use the recipe in BSD

IMHO, the correct formular for the cutoff frequency below (which I guess is 
also used in [hp1~] since the frequency response is the same) is 'common 
knowledge', so I don't think you'd have to pay attention to any licence.


> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
> Von: "Christof Ressi" <christof.re...@gmx.at>
> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
> Cc: pd-list <pd-l...@iem.at>
> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>
> > But coefficients aren't recalculated so
> > often, therefore this difference will be negligible.
> 
> That's a good point. You're right that both involve a feedback and 
> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, 
> iemlib's filters are very efficient.
> 
> Anyway, I researched a bit and found the reason why the frequency response of 
> Pd filters seems 'wrong':
> 
> Miller uses a formular for calculating the cutoff frequency which is taken 
> from analog filters but is not really adequate for digital filters since it 
> doesn't reflect the cyclic nature of the digital domain (although you can see 
> it in some articles on digital filters).
> 
> Let's take [hip~] as an example: 
> 
> the formular for a 1-pole 1-zero highpass goes:
> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
> 
> Miller calculates the position of the pole with 
> k = 1 - (fc * 2*pi / SR).
> 
> The correct formular, however (if you want the frequency response to be zero 
> at Nyquist!), would be 
> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR. 
> 
> You can find it here: 
> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
> 
> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
> clips the coefficient below 0, so it never reaches -1 (where the gain would 
> be all zero).
> 
> Also, there is another approximation with a similiar behaviour, which goes 
> like this: 
> k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.
> 
> Now, is the behaviour of [hip~] 'wrong'?
> If you define at 1-pole 1-zero high pass filter as something which passes 
> everything at fc = DC and blocks everything at fc = Nyquist, then I'd say 
> yes. 
> If it should roughly model an analogue filter (where the cutoff frequency can 
> go up to infinity) for low cutoff frequencies only, then I'd say no.
> 
> Also, as I tried to point out, this issue with the cutoff frequency is true 
> for all Pd filters!
> 
> So I think this behaviour should either be changed (great, if Katja is 
> willing to submit a patch!) or documented in the help patch (gain is not 0 at 
> Nyquist!).
> 
> I'm not an engineer or any expert on filter design. It's just my two cents :-)
> 
> Christof
> 
> 
> 
> 
> 
> > Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
> > Von: katja <katjavet...@gmail.com>
> > An: "Christof Ressi" <christof.re...@gmx.at>
> > Cc: pd-list <pd-l...@iem.at>
> > Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
> >
> > I'm pretty confident [hip~] would not loose its efficiency when using
> > iemlib's recipe. Both hi pass filters have a feed forward and feedback
> > component, with coefficients for normalization and feedback.
> > Calculation of these coefficients is a bit more involved with iemlib's
> > recipe, using trig functions. But coefficients aren't recalculated so
> > often, therefore this difference will be negligible.
> > 
> > To reassure, it is not my intention to spark another 'what's wrong
> > with pd' thread. If iemlib's license allows to use the recipe in BSD
> > code I'll try patch the C of [hip~] and submit on the tracker for
> > review. Who knows, it may be a no-brainer.
> > 
> > Katja
> > 
> > 
> > 
> > 
> > 
> > On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi <christof.re...@gmx.at> 
> > wrote:
> > > There are a number of big problems with all build-in filters in Pd 
> > > (expect for the raw filters).
> > >
> > > Problem number 1:
> > > [lop~] and [hip~] both use a weird (you could also say: wrong) formula 
> > > for the cutoff frequency which makes them gradually converge to a fixed 
> > > output state (reached by about 7000 Hz). The same is true for [vcf~] and 
> > > [bp~] with Q <= 1. Therefore the actual cutoff frequency is only correct 
> > > for very low frequencies and approxim

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread Christof Ressi
> But coefficients aren't recalculated so
> often, therefore this difference will be negligible.

That's a good point. You're right that both involve a feedback and feedforward, 
so I'm wondering why [hp1~] needs more CPU... otherwise, iemlib's filters are 
very efficient.

Anyway, I researched a bit and found the reason why the frequency response of 
Pd filters seems 'wrong':

Miller uses a formular for calculating the cutoff frequency which is taken from 
analog filters but is not really adequate for digital filters since it doesn't 
reflect the cyclic nature of the digital domain (although you can see it in 
some articles on digital filters).

Let's take [hip~] as an example: 

the formular for a 1-pole 1-zero highpass goes:
y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]

Miller calculates the position of the pole with 
k = 1 - (fc * 2*pi / SR).

The correct formular, however (if you want the frequency response to be zero at 
Nyquist!), would be 
k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR. 

You can find it here: 
http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf

BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
clips the coefficient below 0, so it never reaches -1 (where the gain would be 
all zero).

Also, there is another approximation with a similiar behaviour, which goes like 
this: 
k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.

Now, is the behaviour of [hip~] 'wrong'?
If you define at 1-pole 1-zero high pass filter as something which passes 
everything at fc = DC and blocks everything at fc = Nyquist, then I'd say yes. 
If it should roughly model an analogue filter (where the cutoff frequency can 
go up to infinity) for low cutoff frequencies only, then I'd say no.

Also, as I tried to point out, this issue with the cutoff frequency is true for 
all Pd filters!

So I think this behaviour should either be changed (great, if Katja is willing 
to submit a patch!) or documented in the help patch (gain is not 0 at Nyquist!).

I'm not an engineer or any expert on filter design. It's just my two cents :-)

Christof





> Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
> Von: katja <katjavet...@gmail.com>
> An: "Christof Ressi" <christof.re...@gmx.at>
> Cc: pd-list <pd-l...@iem.at>
> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>
> I'm pretty confident [hip~] would not loose its efficiency when using
> iemlib's recipe. Both hi pass filters have a feed forward and feedback
> component, with coefficients for normalization and feedback.
> Calculation of these coefficients is a bit more involved with iemlib's
> recipe, using trig functions. But coefficients aren't recalculated so
> often, therefore this difference will be negligible.
> 
> To reassure, it is not my intention to spark another 'what's wrong
> with pd' thread. If iemlib's license allows to use the recipe in BSD
> code I'll try patch the C of [hip~] and submit on the tracker for
> review. Who knows, it may be a no-brainer.
> 
> Katja
> 
> 
> 
> 
> 
> On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi <christof.re...@gmx.at> wrote:
> > There are a number of big problems with all build-in filters in Pd (expect 
> > for the raw filters).
> >
> > Problem number 1:
> > [lop~] and [hip~] both use a weird (you could also say: wrong) formula for 
> > the cutoff frequency which makes them gradually converge to a fixed output 
> > state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~] 
> > with Q <= 1. Therefore the actual cutoff frequency is only correct for very 
> > low frequencies and approximately gets more and more off until it doesn't 
> > move at all.
> >
> > Problem number 2:
> > [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
> > slope is different for each side and changes with frequency.
> >
> > Problem number 3:
> > the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It 
> > rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 
> > 1!
> >
> > I did some FFT plots, see the attachment.
> >
> > I remember Miller saying somewhere that these filters are not designed for 
> > high cutoff frequencies - but even for low frequencies, the behaviour of 
> > [bp~] and [vcf~] is horrible. I can see these filters are mere 
> > approximations to reduce CPU usage.
> > [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well 
> > suited for DC removal (but not much else).
> > [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
> > latter one has a correct 

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-15 Thread katja
I'm pretty confident [hip~] would not loose its efficiency when using
iemlib's recipe. Both hi pass filters have a feed forward and feedback
component, with coefficients for normalization and feedback.
Calculation of these coefficients is a bit more involved with iemlib's
recipe, using trig functions. But coefficients aren't recalculated so
often, therefore this difference will be negligible.

To reassure, it is not my intention to spark another 'what's wrong
with pd' thread. If iemlib's license allows to use the recipe in BSD
code I'll try patch the C of [hip~] and submit on the tracker for
review. Who knows, it may be a no-brainer.

Katja





On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi  wrote:
> There are a number of big problems with all build-in filters in Pd (expect 
> for the raw filters).
>
> Problem number 1:
> [lop~] and [hip~] both use a weird (you could also say: wrong) formula for 
> the cutoff frequency which makes them gradually converge to a fixed output 
> state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with 
> Q <= 1. Therefore the actual cutoff frequency is only correct for very low 
> frequencies and approximately gets more and more off until it doesn't move at 
> all.
>
> Problem number 2:
> [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
> slope is different for each side and changes with frequency.
>
> Problem number 3:
> the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It 
> rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!
>
> I did some FFT plots, see the attachment.
>
> I remember Miller saying somewhere that these filters are not designed for 
> high cutoff frequencies - but even for low frequencies, the behaviour of 
> [bp~] and [vcf~] is horrible. I can see these filters are mere approximations 
> to reduce CPU usage.
> [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well 
> suited for DC removal (but not much else).
> [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
> latter one has a correct and stable frequency response.
> [vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my 
> laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to 
> consider that [vcf_bp2~] not only acts correctly but lets you set the Q at 
> audio rate. The high CPU usage of [vcf~] seems like a bug to me...
>
> I only use the vanilla filters for the most basic stuff like DC removal and 
> smoothing. I guess these are the use cases which Miller had in mind and that 
> way [lop~] and [hip~] have their justification (although there should be some 
> more warning about the 'wrong' frequency response in the help file).
> But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced 
> by better filters in the future (while keeping the old ones for compatibility 
> reasons).
>
> Christof
>
>
>> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
>> Von: katja 
>> An: pd-list 
>> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>
>> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
>> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
>> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
>> -3 dB at cutoff consistently.
>>
>> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
>> if the license also covers the math. Documentation in
>> https://git.iem.at/pd/iemlib/tree/master points to external literature
>> for part of the math (bilinear transform). I've implemented the recipe
>> with vanilla objects for comparison, see attached.
>>
>> Katja
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

2016-10-14 Thread Christof Ressi
There are a number of big problems with all build-in filters in Pd (expect for 
the raw filters). 

Problem number 1:
[lop~] and [hip~] both use a weird (you could also say: wrong) formula for the 
cutoff frequency which makes them gradually converge to a fixed output state 
(reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. 
Therefore the actual cutoff frequency is only correct for very low frequencies 
and approximately gets more and more off until it doesn't move at all.

Problem number 2:
[bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
slope is different for each side and changes with frequency.

Problem number 3:
the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather 
depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1! 

I did some FFT plots, see the attachment.

I remember Miller saying somewhere that these filters are not designed for high 
cutoff frequencies - but even for low frequencies, the behaviour of [bp~] and 
[vcf~] is horrible. I can see these filters are mere approximations to reduce 
CPU usage.
[hip~] is indeed much more efficient than iemlib's [hp1~], so it's well suited 
for DC removal (but not much else).
[bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
latter one has a correct and stable frequency response.
[vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my 
laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to 
consider that [vcf_bp2~] not only acts correctly but lets you set the Q at 
audio rate. The high CPU usage of [vcf~] seems like a bug to me...

I only use the vanilla filters for the most basic stuff like DC removal and 
smoothing. I guess these are the use cases which Miller had in mind and that 
way [lop~] and [hip~] have their justification (although there should be some 
more warning about the 'wrong' frequency response in the help file). 
But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced 
by better filters in the future (while keeping the old ones for compatibility 
reasons).

Christof


> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
> Von: katja 
> An: pd-list 
> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>
> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
> -3 dB at cutoff consistently.
> 
> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
> if the license also covers the math. Documentation in
> https://git.iem.at/pd/iemlib/tree/master points to external literature
> for part of the math (bilinear transform). I've implemented the recipe
> with vanilla objects for comparison, see attached.
> 
> Katja
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list