[chuck-users] Filters blowing up: any news?

Daniel Trueman dtrueman at Princeton.EDU
Tue Mar 2 10:16:51 EST 2010


i have no idea if this will help, but i've been meaning to bring the old gQ filter stuff to ChucK for sometime. gQ is a really nice filter:

http://www.music.princeton.edu/~dan/gQpage/gQ.html

it might be more stable. maybe not. it usually sounds real nice. in any case, here it is, and it seems to work ok. probably should make a class out of it...

//====================================
//gQ lives!
//dan trueman 2010

Noise n => BiQuad gq => dac;
0.1 => gq.gain;

//need these:
0 => int PEAKNOTCH;
1 => int LOWSHELF;
2 => int HIGHSHELF;
2. * pi => float twopi;
1::second/1::samp => float thisSR;

//set everything
setFreqBoostBandwidth(440., 10., 0.1, LOWSHELF);

//yay, hang out
1::day => now;

//main function for setting biquad params
fun void setFreqBoostBandwidth(float freq, float boost, float thisBandwidth, int type)
{
	float d, a_boost, a_cut, Vzero, true_bw;
	
	freq * thisBandwidth => true_bw;
	boost - 1. => Vzero;
	
	//a's are pole coeffs, b's are zero coeffs

	//PEAK/NOTCH CASE
    if (type == PEAKNOTCH) {   	
		(Math.tan(true_bw*twopi/(2.*thisSR)) - 1.) / (Math.tan(true_bw*twopi/(2.*thisSR)) + 1.) => a_boost;
	    (Math.tan(true_bw*twopi/(2.*thisSR)) - boost) / (Math.tan(true_bw*twopi/(2.*thisSR)) + boost) => a_cut;
	    -Math.cos(freq*twopi/thisSR) => d; 
	     
		/* cut */
		if(boost <= 1.0) {
	    	1.0 + (1.0 + a_cut)*Vzero/2.0 => gq.b0;
	    	d*(1 - a_cut) => gq.b1;
	    	(-a_cut - (1 + a_cut)*Vzero/2.0) => gq.b2;

	    	d*(1.0 - a_cut) => gq.a1;
	    	-a_cut => gq.a2; 
		} 

		/* boost */     
		if(boost > 1.0) {
	    	1.0 + (1.0 + a_boost)*Vzero/2.0 => gq.b0;
	    	d*(1 - a_boost) => gq.b1;
	    	(-a_boost - (1 + a_boost)*Vzero/2.0) => gq.b2;

	    	d*(1.0 - a_boost) => gq.a1;
	    	-a_boost => gq.a2; 
		}			
	}
	
	//LOW SHELF CASE
	 else if (type == LOWSHELF) {   	
		(Math.tan(freq*twopi/(2.*thisSR)) - 1.) / (Math.tan(freq*twopi/(2.*thisSR)) + 1.) => a_boost;
	    (Math.tan(freq*twopi/(2.*thisSR)) - boost) / (Math.tan(freq*twopi/(2.*thisSR)) + boost) => a_cut;
	     
		/* cut */
		if(boost <= 1.0) {
	    	1.0 + (1.0 + a_cut)*Vzero/2.0 => gq.b0;
	    	a_cut + (1 + a_cut)*Vzero/2.0 => gq.b1;
	    	0. => gq.b2;

	    	a_cut => gq.a1;
	    	0. => gq.a2; 
		} 

		/* boost */     
		if(boost > 1.0) {
	    	1.0 + (1.0 + a_boost)*Vzero/2.0 => gq.b0;
	    	a_boost + (1 + a_boost)*Vzero/2.0 => gq.b1;
	    	0. => gq.b2;

	    	a_boost => gq.a1;
	    	0. => gq.a2;
		}			
	}
	
	//HIGH SHELF CASE
	 else if (type == HIGHSHELF) {   	
		(Math.tan(freq*twopi/(2.*thisSR)) - 1.) / (Math.tan(freq*twopi/(2.*thisSR)) + 1.) => a_boost;
	    (boost*Math.tan(freq*twopi/(2.*thisSR)) - 1.) / (boost*Math.tan(freq*twopi/(2.*thisSR)) + 1.) => a_cut; 
	     
		/* cut */
		if(boost <= 1.0) {
	    	1.0 + (1.0 - a_cut)*Vzero/2.0 => gq.b0;
	    	a_cut + (a_cut - 1.)*Vzero/2.0 => gq.b1;
	    	0. => gq.b2;

	    	a_cut => gq.a1;
	    	0. => gq.a2; 
		} 

		/* boost */     
		if(boost > 1.0) {
	    	1.0 + (1.0 - a_boost)*Vzero/2.0 => gq.b0;
	    	a_boost + (a_boost - 1.)*Vzero/2.0 => gq.b1;
	    	0. => gq.b2;

	    	a_boost => gq.a1;
	    	0. => gq.a2; 
		}			
	}
}
//====================================

On Mar 1, 2010, at 4:48 PM, Tomasz Kaye's brain wrote:

> Hi Robert. Thanks for the pointer, that's very useful.
> 
> I'd stayed away from RezonZ until now because I thought it would be wisest to begin by using filter types I already knew (or thought i knew) from other environments: LPF BPF and HPF.
> 
> I saw that RezonZ doesn't have the runaway tendency of the other three when plugged into the test patch (and now I think I understand the significance of the line in the RezonZ ugen documentation: "keeps gain under control independent of frequency").
> 
> I'll have a try at getting RezonZ act as a rough approximation of the other three filter types (any further pointers anyone can offer in this direction would be great), and try again to do some reading around musical applications of biquad filters, though filter-related writing tends to make my head hurt :)
> 
> On Mon, Mar 1, 2010 at 9:00 PM, Robert Poor <rdpoor at gmail.com> wrote:
> Tomasz:
> 
> I use SndBuf => ResonZ => Envelope => DAC frequently in live
> performances.  Even though the center frequency and Q of the ResonZ
> are controlled by pitch bend and modulation wheel (respectively), I've
> never had any problems with stability.  Am I missing something?  :)
> 
> - Rob
> 
> 2010/3/1 Tomasz Kaye's brain <tomasz.brain at gmail.com>:
> > About the filter problem: does it mean that currently no one is using chuck
> > for classic sutractive synthesis patches like:
> >
> > Oscillators -> Filters (cuttof driven by an ADSR) -> Amplifier (Level driven
> > by an ADSR) ?
> >
> > Are people just not doing this kind of routing in ChucK yet, or are there
> > workarounds that avoid the filters going unstable when modulated in this
> > way?
> >
> > (Sorry to keep on about this, but I'm really keen to keep using ChucK if at
> > all possible)
> >
> > 2010/2/17 mike clemow <michaelclemow at gmail.com>
> >>
> >> OT:
> >>
> >> 2010/2/16 Andrew C. Smith <andrewchristophersmith at gmail.com>
> >>>
> >>> Seems that ChucK can crash brains, not just computers!
> >>
> >> Chuck's filter code is actually written in Sumerian.  The Goddess Asherah
> >> created Chuck to erase peoples' minds and make them worship her.  The sound
> >> is actually a nam-shub and if you hear it, you will lose your wits and start
> >> mumbling Sumerian syllables...
> >>
> >> (sorry, i couldn't help this outburst.  i finished the book just a few
> >> short weeks ago.  ;)
> >>
> >> -Mike
> >>
> >>
> >>
> >>
> >>>
> >>> Actually, my other solution was to run the audio through Jack and into
> >>> Logic, where I can do a much better job of controlling the volume. This
> >>> actually doesn't distort (since the distortion comes at the dac level), and
> >>> changes the sound entirely. Anyway, just an option.
> >>> -Andrew
> >>> On Feb 16, 2010, at 5:03 PM, Kassen wrote:
> >>>
> >>>
> >>> 2010/2/16 Stefan Blixt <stefan.blixt at gmail.com>
> >>>>
> >>>> If you do SinOsc s=> dac and the 100.0 => s.gain, are you then able to
> >>>> blow a speaker on a Mac laptop even if it's main volume is turned down?
> >>>> That's the curious thing to me, how the filter messes up so badly it makes
> >>>> my MacBook's speaker scream even though the volume is almost down to zero.
> >>>>
> >>>
> >>> 100? Try something like this value for a output; 242210436022272.0
> >>> That's a actual recorded output of .last(). I'm not sure what would
> >>> happen if something of that volume would be played back on real speakers;
> >>> there is probably a UN convention against that kind of thing ;-).
> >>>
> >>> From what I understand of the situation you wouldn't blow the speaker. If
> >>> Apple was smart they put in a pre-amp that's slightly smaller than the
> >>> maximum load of the speaker yet slightly over-speced for the output of the
> >>> dac to keep repairs down. But yes; apparently you will can get a very high
> >>> volume even though the (software) fader is down.
> >>> This is what we know.
> >>> Then from that I speculated (and unless something more credible comes by
> >>> I think it's a good theory) that Apple is doing everything in float (with
> >>> virtually unlimited headroom for practical applications), setting the master
> >>> volume with a floating point multiplication, and handing the resultant value
> >>> to the dac where inevitably it will be turned into a plain integer. In this
> >>> case that integer will be the highest volume the poor little dac can take.
> >>> If that's not it I can't imagine why +/- some 15 digit number would have a
> >>> higher amplitude than +/-1, as a final output, post master fader.
> >>> This is cheap compared to tweaking the voltage on the final hardware amp
> >>> (which would always preserve the full bit-range) and probably sounds a lot
> >>> better than going integer and throwing away a lot of bits at low volume, but
> >>> it fails to take into account that we may not just turn the volume down for
> >>> a more pleasant listen but also to protect our ears. Combine that with with
> >>> potentially very sensitive studio or DJ headphones and you have a situation
> >>> that may lead to hearing damage. I know that my own pro DJ headphones will
> >>> output a lot more volume than my mid-range earbuds at the same volume
> >>> setting for a headphone jack.
> >>>
> >>> IMHO this would be a oversight by Apple and I'm a bit surprised there
> >>> hasn't been a storm of practical joke mails aimed at OSX users featuring
> >>> videoclips embedding floating-point audio. I'd offer at least a optional
> >>> output limiter like what has been proposed for mp3 players. I don't believe
> >>> in those for protecting children's ears through mandatory regulation because
> >>> of the differences in headphone output volume, but for user-set protection
> >>> it might be a good idea. Of course ChucK is a bit more likely to cause this
> >>> sort of issue than the average off-the-shelf audio player.
> >>> Here is the original topic if you'd like to try to reproduce the findings
> >>> so far; http://electro-music.com/forum/viewtopic.php?t=37921
> >>> Yours,
> >>> Kas.
> >>> _______________________________________________
> >>> chuck-users mailing list
> >>> chuck-users at lists.cs.princeton.edu
> >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >>>
> >>>
> >>> _______________________________________________
> >>> chuck-users mailing list
> >>> chuck-users at lists.cs.princeton.edu
> >>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >>>
> >>
> >>
> >>
> >> --
> >> http://michaelclemow.com
> >> http://semiotech.org
> >>
> >>
> >> _______________________________________________
> >> chuck-users mailing list
> >> chuck-users at lists.cs.princeton.edu
> >> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >>
> >
> >
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >
> >
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> 
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100302/9e2f7e5f/attachment-0001.html>


More information about the chuck-users mailing list