Re: [PD] [sqosc~]-issues
Roman Haefeli wrote: hi again i've come a bit closer to the source of the problem: when i load patch that contains a [sqosc~], whose first inlet~ is connected with a tilde-object, that sends a zero-signal immediately after loading the patch (e.g [line~]), the first outlet~ of [sqosc~] sends a 'nan' (not a number?). at least, this is what [env~]-[nbx] tells me. Thanks for the feedback Roman. I just now put a modified sqosc~.c in cvs; it calls finite() to detect NaNs and replace them with zeros. I only tested it on WinXP so far. Maybe you could try the new version and see if it works better. Thanks, Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
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
Re: [PD] [sqosc~]-issues
On Sun, 2007-03-25 at 21:46 -0400, Martin Peach wrote: Roman Haefeli wrote: i tested your external a bit more deep on the 'good' soundcard, where i can exclude aliasing introduced by the soundcard. it turned out, that a bit of aliasing is audible in the range above 5000Hz. i think this is not tooo bad, maybe for 'pure'ists. Do you get the aliasing also with [osc~]? no, not when i test on the 'good' card. when playing [osc~] or the bandlimited oscillators i posted in previous mails, there is absolutely no aliasing hearable (on the rme-card). i tested all with an sr=44100Hz. there is somethings else, i forgoto mention: when playing [sqosc~] with low frequencies (100Hz), it sounds a bit dull compared to a raw square with the same amplitude and the same frequency. does [sqosc~] not play the full spectrum in the low area? roman ___ 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
Re: [PD] [sqosc~]-issues
On Sun, 2007-03-25 at 21:46 -0400, Martin Peach wrote: Chris McCormick wrote: On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote: [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes. How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC! hehe, actually i am not sure, if my soundcard physically outputs dc or if the output is high pass filtered. maybe i should elaborate a bit more my setup and what i did in order to explain, why i assume dc on the output. i run pd over jackd and jackd runs on the rme card. the hdspmixer has a levelmeter for each input and output, so i can see the signal-levels that are sent from jackd to the outputs of the card. here the jack-routing: pd out 1 - hdsp out 1 pd out 2 - hdsp out 2 now, when i load the help-patch of [sqosc~], the level-meters of hdsp out 1 and 2 show full amplitude and i hear a hard click on the loudspeakers (similar to the sound, when sending dc to the speakers). when i close the patch, the amplitude remains. when i disconnect pd from jack, the amplitude goes away and i hear a hard click again. but even if i restart pd, the amplitude comes immediately again (with the loud click, of course). also if i connect other softwares over jack to the hdsp out 1 and 2, the high amplitude comes again. to get rid of that, i must restart jack. but as soon as i load the help-patch of [sqosc~] again, i have the same situation again (loud click and full amplitude on the meters). i don't know of any other setup with that behaviour. this happens only, when i load a patch with one or more [sqosc~]s. that is why i assume, it is (at least a bit) related to [sqosc~]. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
I get nan when I blow up a filter or delay line. It's synonymous with pure DC offset to me. The soundcard of course filters it, but it's basically a pure positive or negative signal up to that point. Some LADSPAs do it to me as well, like Foldover Distortion and some others. best, d. Roman Haefeli wrote: hi again i've come a bit closer to the source of the problem: when i load patch that contains a [sqosc~], whose first inlet~ is connected with a tilde-object, that sends a zero-signal immediately after loading the patch (e.g [line~]), the first outlet~ of [sqosc~] sends a 'nan' (not a number?). at least, this is what [env~]-[nbx] tells me. when i change the frequency to some non-zero value and change it back to zero, [env~]-[nbx] says '96.47', which is the expected value, i think. i assume, this 'nan'-signal is the reason, why my jackd goes crazy. the problem does not occur anymore when i send [0.001, 0 1( to the [line~] on loadbang. i attached a little test-patch to show you, what happens here. i couldn't test it on other systems/versions of pd/audio-apis. roman On Sun, 2007-03-25 at 21:46 -0400, Martin Peach wrote: Chris McCormick wrote: On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote: [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes. How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC! Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 276 167 640 276 10; #X obj 25 80 sqosc~ 300 0.5 15000; #X obj 25 103 env~; #X floatatom 25 125 0 0 0 0 - - -; #X obj 25 53 sig~ 0; #X obj 227 76 sqosc~ 300 0.5 15000; #X obj 227 99 env~; #X floatatom 227 121 0 0 0 0 - - -; #X obj 227 50 sig~ 1; #X text 226 28 non-zero signal; #X text 27 27 zero signal; #X text 84 129 - nan; #X text 287 123 - 96.48; #X obj 448 142 sqosc~ 300 0.5 15000; #X obj 448 165 env~; #X floatatom 448 187 0 0 0 0 - - -; #X obj 447 65 loadbang; #X text 443 29 solution; #X msg 447 91 5 \, 0 1; #X obj 447 118 line~; #X text 505 190 - 96.48; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 3 0 0 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 7 0 4 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 15 0 17 0; #X connect 17 0 18 0; #X connect 18 0 12 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 57: Do the words need changing? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
On 3/26/07, Derek Holzer [EMAIL PROTECTED] wrote: I get nan when I blow up a filter or delay line. It's synonymous with pure DC offset to me. The soundcard of course filters it, but it's basically a pure positive or negative signal up to that point. Some LADSPAs do it to me as well, like Foldover Distortion and some others. I've generated some inf and -inf's, before when trying to write externals... To my recollection, those numbers were treated as 0's when passed through an outlet (returned by the function). Your explanation makes a lot of sense, but it still seems like a mystery to me. Chuck ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
On 3/26/07, Martin Peach [EMAIL PROTECTED] wrote: 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'm reading through the math headers, and there's functions isinf(x) and isnan(x) I'm not yet sure of the syntax it's not so common to see these, like this. Typically the math functions will add 'f' at the end to denote a float argument, instead of a double. Probably there's more I haven't found yet 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. it is coming from tabosc~ (I think)... it's just one of those problems where the lack of default arguments leads to an unexpected result... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
okay, (on linux) you find math.h in /usr/include/ which includes a file /usr/include/bits/mathcalls.h there are three functions int finite(double x) -- returns 1, if x is not NaN or inf int isinf(double x) -- returns 1, if x is inf or -inf int isnan(double x) -- returns 1, if x is NaN int finitef(float x), int isnanf(float x), and int isinff(float x) are the float versions. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
Thanks, Charles, For Windows, I found int _isnan(double x) in float.h; it returns non-zero if x is NaN. Also in float.h, int _finite(double x) returns zero if the number is +- infinite or a NaN, so that would seem to cover every possibility. and int _fpclass(double x) returns a specific code for each type of NaN as well as zero and non-zero numbers. There don't seem to be any float versions of these. If the overhead is not too high it would make sense to use one of these in any dsp routine that might generate such values. Ideally it should be on the input to [dac~] so it only needs to be called once per sample, but I'll try it on sqosc~ to see what happens... Martin Charles Henry wrote: okay, (on linux) you find math.h in /usr/include/ which includes a file /usr/include/bits/mathcalls.h there are three functions int finite(double x) -- returns 1, if x is not NaN or inf int isinf(double x) -- returns 1, if x is inf or -inf int isnan(double x) -- returns 1, if x is NaN int finitef(float x), int isnanf(float x), and int isinff(float x) are the float versions. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [sqosc~]-issues
hm.. it seems that the previous mail wasn't sent here again: hello martin peach i tested your external a bit more deep on the 'good' soundcard, where i can exclude aliasing introduced by the soundcard. it turned out, that a bit of aliasing is audible in the range above 5000Hz. i think this is not tooo bad, maybe for 'pure'ists. but i had serious troubles, when loading some patches, that contain [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of the dc, i must restart jackd again. because of that, i assume it is related to jackd (is it possible to crash jackd from pd?). i attached a test-patch. when loading that patch, jackd (and pd) get unusable for sure. my system: ubuntu dapper i386 pd-0.40.2 jackd 0.100.0 when i create a patch from scratch with [sqosc~], i have no troubles. i get the dc also, when i open the help-patch of [sqosc~]. roman ___ 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
Re: [PD] [sqosc~]-issues
and forgot the attachment this time. no day without that. On Sun, 2007-03-25 at 20:42 +0200, Roman Haefeli wrote: hm.. it seems that the previous mail wasn't sent here again: hello martin peach i tested your external a bit more deep on the 'good' soundcard, where i can exclude aliasing introduced by the soundcard. it turned out, that a bit of aliasing is audible in the range above 5000Hz. i think this is not tooo bad, maybe for 'pure'ists. but i had serious troubles, when loading some patches, that contain [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of the dc, i must restart jackd again. because of that, i assume it is related to jackd (is it possible to crash jackd from pd?). i attached a test-patch. when loading that patch, jackd (and pd) get unusable for sure. my system: ubuntu dapper i386 pd-0.40.2 jackd 0.100.0 when i create a patch from scratch with [sqosc~], i have no troubles. i get the dc also, when i open the help-patch of [sqosc~]. roman ___ Der frhe Vogel fngt 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 #N canvas 199 183 633 300 10; #X obj 54 134 sqosc~ 300 0.5 15000; #X obj 55 244 dac~; #X obj 54 179 *~; #X obj 146 215 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 6400 1; #X obj 143 235 pow 2; #X obj 56 38 hsl 128 15 20 15000 1 0 empty empty empty -2 -8 0 10 -262144 -1 -1 0 1; #X obj 53 102 line~; #X obj 143 278 line~; #X obj 143 256 pack f 50; #X obj 53 79 pack f 100; #X obj 163 98 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 6700 1; #X obj 226 161 line~; #X obj 226 139 pack f 50; #X obj 350 130 sqosc~ 300 0.5 15000; #X obj 351 240 dac~; #X obj 350 175 *~; #X obj 442 211 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 4900 1; #X obj 439 231 pow 2; #X obj 352 34 hsl 128 15 20 15000 1 0 empty empty empty -2 -8 0 10 -262144 -1 -1 5400 1; #X obj 349 98 line~; #X obj 439 274 line~; #X obj 439 252 pack f 50; #X obj 349 75 pack f 100; #X obj 459 94 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 5200 1; #X obj 522 157 line~; #X obj 522 135 pack f 50; #X connect 0 0 2 0; #X connect 2 0 1 0; #X connect 2 0 1 1; #X connect 3 0 4 0; #X connect 4 0 8 0; #X connect 5 0 9 0; #X connect 6 0 0 0; #X connect 7 0 2 1; #X connect 8 0 7 0; #X connect 9 0 6 0; #X connect 10 0 0 2; #X connect 12 0 11 0; #X connect 13 0 15 0; #X connect 15 0 14 0; #X connect 15 0 14 1; #X connect 16 0 17 0; #X connect 17 0 21 0; #X connect 18 0 22 0; #X connect 19 0 13 0; #X connect 20 0 15 1; #X connect 21 0 20 0; #X connect 22 0 19 0; #X connect 23 0 13 2; #X connect 25 0 24 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [sqosc~]-issues
hello martin peach i tested your external a bit more deep on the 'good' soundcard, where i can exclude aliasing introduced by the soundcard. it turned out, that a bit of aliasing is audible in the range above 5000Hz. i think this is not tooo bad, maybe for 'pure'ists. but i had serious troubles, when loading some patches, that contain [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of the dc, i must restart jackd again. because of that, i assume it is related to jackd (is it possible to crash jackd from pd?). i attached a test-patch. when loading that patch, jackd (and pd) get unusable for sure. my system: ubuntu dapper i386 pd-0.40.2 jackd 0.100.0 when i create a patch from scratch with [sqosc~], i have no troubles. i get the dc also, when i open the help-patch of [sqosc~]. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote: [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes. Best, Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
Roman Haefeli wrote: i tested your external a bit more deep on the 'good' soundcard, where i can exclude aliasing introduced by the soundcard. it turned out, that a bit of aliasing is audible in the range above 5000Hz. i think this is not tooo bad, maybe for 'pure'ists. Do you get the aliasing also with [osc~]? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [sqosc~]-issues
Chris McCormick wrote: On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote: [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes. How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC! Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
