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

[Tomasz Kaye's brain]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100301/dbb1679d/attachment.html>