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
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list