Re: [sc-users] The curse of the blowups

["Sean Costello" <seancostello2003@xxxxxxxxxxx>]

If the amplitude of a signal goes to +- infinity (i.e. the limits of the
floating point number system), it is very close to blowing up. In floating
point, INF+INF = NaN.

You could check for NaNs in your signal, but you probably don't want
infinite gain in the first place.

A few tricks:

- Use rotation matrices to mix signals together for feedback. Same idea as
unitary networks for reverb (see Miller Puckette's online book for details),
but applied to whatever signal processing things you are using.
- Use clips, soft saturation, limiters, etc. to keep the signal within known
bounds. A limiter can do some nice things in a feedback network. Soft
saturation will get you closer to what happens in an analog network, but can
cause aliasing that might be undesirable.

Sean Costello

----- Original Message ----- 
From: "Joshua Parmenter" <joshpar@xxxxxxx>
To: "Dan Stowell" <danstowell@xxxxxxxxx>; "SuperCollider users mailing list"
<sc-users@xxxxxxxxxxxxxxx>
Sent: Wednesday, September 21, 2005 2:01 PM
Subject: Re: [sc-users] The curse of the blowups


> division by 0 will cause a blowup I believe.
>
> Josh
>
> On Sep 21, 2005, at 1:23 PM, Dan Stowell wrote:
>
> > Hi,
> >
> > I'm doing a lot of work on evolutionary synth generation (as
> > mentioned/linked before), and because the networks that are generated
> > are so unpredictable, occasionally I'll get a blowup. Please stop me
> > if I'm using the term incorrectly - but what I'm referring to is the
> > condition when all output completely stops, only solvable by rebooting
> > the server. In one case I found it could be caused by a UGen being
> > tricked into outputting "NaN" rather than a real number.
> >
> > So I have some related questions:
> >
> > * Is there any way at all to "catch" blowups or to recover from them
> > without having to kill the server?
> > * Does anyone know of specific conditions which might cause blowups?
> > I'm not using any particularly weird UGens...
> > * Should this kind of problem be treated as a bug (assuming I'm not
> > using anything like FSinOsc which comes with a blowup warning)? I
> > would hope that an SC user should be insulated from this kind of
> > thing, but perhaps the decision has been to sacrifice that kind of
> > insulation in favour of faster code...?
> >
> > Thanks
> > Dan
> >
> >
> > --
> > http://www.mcld.co.uk
> >
> > _______________________________________________
> > sc-users mailing list
> > sc-users@xxxxxxxxxxxxxxx
> > http://www.create.ucsb.edu/mailman/listinfo/sc-users
> >
>
> _______________________________________________
> sc-users mailing list
> sc-users@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-users