Does anyone know how to tell, in c, if you're getting nans? It should be easy enough in the dsp routine to replace nans with zeros. It's just a question of detecting them in time. I remember you could do it in SANE, the old Apple math system, there was some function like isnan(). I don't see how [sqosc~] could be generating them though, since it's deliberately operating in a fixed range of float, the same way [osc~] does.
Martin
Derek Holzer wrote:
After having done lots of work with recursive feedback structures in PD using delays and filters, I can positively say that PD (rather then Jack) is making the problem in every one of my cases. YMMV. But for me, it always happens when delay lines or resonant filters become feedback saturated to the point of being pure DC. The offending object must then be cut and pasted (i.e. reset) to get rid of the "nan" signal, so try cut/paste rather than restart and see if it helps you next time. I've always considered this something that is inherent in DSP with no sanity checks, as PD often is, rather than a bug specific to PD. The CSound manual mentions this "blowing up" of filters quite frequently, so I know it happens in other applications.
best, d.
padawan12 wrote:
I get this too. It's never seemed worth filing a bug report because it's not clear whether Pd or an external or Jack itself it where the problem occurs. Sometimes a channel just locks up and all I can get is nans until the application is restarted. It's quite rare, but annoying if it happens during a talk or performance.