electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
Live streaming at radio.electro-music.com

  host / artist show at your time
  Faux Pas Quartet and friends Music From Last Thursday
Please visit the chat
 Forum index » DIY Hardware and Software » ChucK programming language
Why do filters scream sometimes?
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [13 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Sat Nov 07, 2009 3:02 pm    Post subject: Why do filters scream sometimes? Reply with quote  Mark this post and the followings unread

The following code (don't run it, for the sake of your ears) results in a deafening scream-like sound. I'd like to understand why (so I can avoid accidentally creating these noise shocks).

I'm guessing it's to do with the BPF wth it's frequency set to 20000. Any insights greatly appreciated!

Code:
PulseOsc osc => ADSR env => BPF filter => dac;
20000=>filter.freq;
0.5=>filter.Q;
while(true){
   1::second=>now;
   env.keyOn();
   20::ms=>now;
   env.keyOff();
}

_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
Antimon



Joined: Jan 18, 2005
Posts: 3730
Location: Sweden
Audio files: 275
G2 patch files: 96

PostPosted: Sun Nov 08, 2009 2:54 am    Post subject: Reply with quote  Mark this post and the followings unread

This happens to me every now and then too. At first I thought it might be because you have leave the gain at unity, but doing 0.1 => filter.gain and 0.1 => osc.gain did hardly anything, even though I have a really low volume. Weird!

/Stefan

_________________
Antimon's Window
@soundcloud @Flattr home - you can't explain music
Back to top
View user's profile Send private message Visit poster's website
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Sun Nov 08, 2009 3:03 am    Post subject: Reply with quote  Mark this post and the followings unread

Yes, this was shocking for me because I always turn my laptop level right down when trying new audio code, but even with that precaution, the above code seemed to blast out at full volume, very alarming!
_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Sun Nov 08, 2009 4:55 am    Post subject: Reply with quote  Mark this post and the followings unread

I'm no DSP or Programming/Algorithm expert, but let's take a look at my inspection on the result first:

Code:
PulseOsc osc => BPF filter => blackhole;
20000 => filter.freq;
0.5 => filter.Q;
for(int i; i < 100; i++)
{
    <<< "osc: ", osc.last(), " filter: ", filter.last() >>>;
    samp => now;
}


We see the filtered result rises unstoppably all the time. This will surely overloaded the DAC very fast, and you might have to set DAC's gain to 1/MaxFloat to not let it clip hahahahah.. (seems silly)..

But i always suspected it has something to do with the combination of both freq and Q. First, i'll try to lower the filter's freq to the point that it won't behave like this:

Code:
PulseOsc osc => BPF filter => blackhole;
11000 => filter.freq;
0.5 => filter.Q;
for(int i; i < 100; i++)
{
    <<< "osc: ", osc.last(), " filter: ", filter.last() >>>;
    samp => now;
}


Ok, the result looks safer. How about changing the Q?
Around Q = 0.9, the filtered value still rises, but with Q = 1.0, it stops and behave just like what we'd like to se:

Code:
PulseOsc osc => BPF filter => blackhole;
20000 => filter.freq;
1.0 => filter.Q;
for(int i; i < 100; i++)
{
    <<< "osc: ", osc.last(), " filter: ", filter.last() >>>;
    samp => now;
}


So, i still don't know the math, but ok when i have to filter it out with very high freq, i normally increase the Q according to freq also so that it won't explode. for example:

Code:
PulseOsc osc => BPF filter => dac;
TriOsc lfo => blackhole;
0.5 => lfo.freq;

.1 => filter.gain;

while(true)
{
    (lfo.last() + 1)/2 * 22000 => filter.freq;
    (lfo.last() + 1)/2 * 4 + .5 => filter.Q;
    10::samp => now;
}


Yeah. This seems dangerous at first (with this high freq) but when played, comes out pretty smooth. And it's safe to change filter to LPF, HPF also --> it still function correctly. Even if we increase the filter.freq to 30000 = beyond nyquist frequency here with my VM running at sample rate = 44100, it still doesn't blow up.

So, one of my favourite solution is to increase Q according to the increased freq. I don't know the math behind this, but it does the trick and safe our ears. Maybe the ChucK developer team can identify the reason of this behavior from the butterworth codes in ChucK source code.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Sun Nov 08, 2009 5:35 am    Post subject: Reply with quote  Mark this post and the followings unread

Code:
PulseOsc osc => BPF filter => LPF test => blackhole;
20000 => filter.freq;
0.5 => filter.Q;

22050 => test.freq;

for(int i; i < 100; i++)
{
    <<< "osc: ", osc.last(), " filter: ", filter.last(), "  test: ", test.last() >>>;
    samp => now;
}


This also stopped it from blowing up, but i don't know how safe it is.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Mon Nov 09, 2009 8:23 am    Post subject: Reply with quote  Mark this post and the followings unread

Thanks kijjaz, its nice to notice how simple it is to do per-sample debugging with chuck.

I'd like to get a better idea of exactly how (and when) Q and frequency interact to create the screaming effect, (that would be quite disastrous during an ambient interlude Wink ). Will post back if I learn anything more.

_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Mon Nov 09, 2009 9:28 am    Post subject: Reply with quote  Mark this post and the followings unread

cbit wrote:

I'd like to get a better idea of exactly how (and when) Q and frequency interact to create the screaming effect,


I think they simply become what is called "unstable" in filter design. It's fairly well understood how to prevent that (by science, I mean, not by me Smile ).

I noticed the same thing, BTW, it totally wrecked the start of one of my last livecode sessions on live radio. I don't know what I did to get it under controll, probably just change freq and Q randomly.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Wed Nov 11, 2009 7:13 am    Post subject: Reply with quote  Mark this post and the followings unread

kijjaz wrote:
Code:
PulseOsc osc => BPF filter => LPF test => blackhole;
20000 => filter.freq;
0.5 => filter.Q;

22050 => test.freq;

for(int i; i < 100; i++)
{
    <<< "osc: ", osc.last(), " filter: ", filter.last(), "  test: ", test.last() >>>;
    samp => now;
}


This also stopped it from blowing up, but i don't know how safe it is.


That's odd. When I run this one, I do get the runaway 'blow up' effect (intel macbook).

Code:
osc:  0.000000  filter:  0.000000
osc:  1.000000  filter:  -0.429949
osc:  1.000000  filter:  0.747586
osc:  1.000000  filter:  -1.247810
osc:  1.000000  filter:  2.027038
osc:  1.000000  filter:  -3.230805
osc:  1.000000  filter:  5.078371
osc:  1.000000  filter:  -7.899556
osc:  1.000000  filter:  12.189869
osc:  1.000000  filter:  -18.692963
osc:  1.000000  filter:  28.523933
osc:  1.000000  filter:  -43.353687
osc:  1.000000  filter:  65.684448
osc:  1.000000  filter:  -99.261597
osc:  1.000000  filter:  149.688995

[snip...]

osc:  1.000000  filter:  396605358080.000000
osc:  1.000000  filter:  -592206823424.000000
osc:  1.000000  filter:  884276723712.000000
osc:  1.000000  filter:  -1320392327168.000000
osc:  1.000000  filter:  1971595116544.000000
osc:  1.000000  filter:  -2943963103232.000000
osc:  1.000000  filter:  4395892736000.000000
osc:  1.000000  filter:  -6563897540608.000000
osc:  1.000000  filter:  9801136340992.000000
osc:  1.000000  filter:  -14634940628992.000000
osc:  1.000000  filter:  21852720201728.000000
osc:  1.000000  filter:  -32630219210752.000000
osc:  1.000000  filter:  48723056918528.000000
osc:  1.000000  filter:  -72752694296576.000000
osc:  1.000000  filter:  108633480232960.000000
osc:  1.000000  filter:  -162210244460544.000000
osc:  1.000000  filter:  242210436022272.000000
osc:  1.000000  filter:  841182498258944.000000
osc:  1.000000  filter:  -0.429949
osc:  1.000000  filter:  0.747586

_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed Nov 11, 2009 9:59 am    Post subject: Reply with quote  Mark this post and the followings unread

cbit wrote:

That's odd. When I run this one, I do get the runaway 'blow up' effect (intel macbook).


My bet is that Kijjaz is running audio at 48KHz while you will be at 44.1KHz (I think those are the Linux & Mac defaults and I think those are your platforms). For digital filters sample rate matters. A given cut-off will mean different coefficients for different sample rates and in this case one of those may have a instability-causing rounding error. At other frequencies the reverse may hold true.

I think I'm going to report this to the list where we may reach Perry. Perry is probably our digital filter expert.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
kijjaz



Joined: Sep 20, 2004
Posts: 765
Location: bangkok, thailand
Audio files: 4

PostPosted: Thu Nov 12, 2009 11:08 am    Post subject: Reply with quote  Mark this post and the followings unread

hmm.. i see. i'll look more into this.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Sun Nov 15, 2009 6:16 am    Post subject: Reply with quote  Mark this post and the followings unread

Looking around some more i noticed that BiQuad filter class has .norm (normalization) and .eqzs (equal gain zeroes) parameters. Hunting on the chuck list suggests to me that these parameters relate to an auto 'anti-blowing-up capability' of the BiQuad filter class.

The HP BP and LP have no such params. I understand that it's possible to use BiQuad to recreate these standard types (while taking advantage of its anti-blowup functionality?), but unfortunately that's a task way beyond my modest understanding of filter design.

(I've started reading introductory papers, but my eyes glaze over before anything starts to make sense. I have the feeling that smarter people than me must have already figured this stuff out Wink )

I'm surprised that there doesn't seem to be a built-in set of 'safe' standard filters in ChucK, of the kind that exist in all other audio synthesis environments I've used (HP BP LP BR). I think the existence of a set like this would go a long way towards increasing the accessibility of ChucK for new users.

If I'm interpreting the situation correctly, is there hope of something like this for the future?

_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Nov 15, 2009 1:04 pm    Post subject: Reply with quote  Mark this post and the followings unread

Actually, LPF, BPF, HPF and ResonZ are supposed to be the convenience ones. I think they should be normalised already. They just don't work like they should Smile.

I think this is a bug that should be fixed. If all is well Perry should be looking into it.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
cbit



Joined: Dec 01, 2005
Posts: 35

PostPosted: Sun Nov 15, 2009 1:06 pm    Post subject: Reply with quote  Mark this post and the followings unread

Oh that's great! thanks for passing it on.
_________________
http://basementhum.blogspot.com
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [13 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use