On Tue, 2007-03-27 at 01:37 +0200, 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.
sometimes it helps to delete the object, that outputs a 'nan'-signal. but sometimes, as andy said, just cutting this object doesn't help to get rid of the 'nan'. i even had some cases, where i had to restart jackd. i don't know the internals behind pd/jackd, but i can say for sure, that it is _possible_ to turn jackd unusuable with a 'nan'-signal (i don't say, it happens each time). but i can't tell, whether pd or jackd is the cause of the problem (maybe both?).
roman
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.
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de