[PD] sigmund~ track analysis errors
Hi list, Related to the bug report https://github.com/pure-data/pure-data/issues/872 , I wanted to drop some questions about sigmund: - when using the "-npeak x tracks" settings, the X stands for the maximum number of tracks, and no more are allowed. Is this the expected behavior? It's not documented in the help file. More important, I was getting inconsistent track analysis results with sigmund~, and I think I found a way of confirming this. Basically, after the first analysis lots of low frequencies disappear - only resetting/recreating the object makes it possible to do the analysis. The patch attached should be clear, can anyone confirm if this also happens with other systems? (done with windows 7, pd 64b) Best, Joao #N canvas 123 72 516 603 10; #X obj 19 398 print peak; #N canvas 0 50 450 300 (subpatch) 0; #X array test 155944 float 2; #X coords 0 1 155944 -1 200 140 1 0 0; #X restore 73 446 graph; #X obj 304 533 phasor~; #X obj 304 445 loadbang; #X obj 304 481 440; #X floatatom 303 508 5 0 0 0 - - -; #X obj 280 536 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 350 481 \; pd dsp 1; #X obj 19 259 until; #X obj 20 238 20; #X obj 20 217 t b b; #X obj 20 196 bng 15 250 50 0 empty empty empty 17 7 0 10 -4034 -1 -1; #X obj 313 325 soundfiler; #X obj 313 285 openpanel; #X obj 313 258 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 19 326 t f f; #X obj 76 316 + 204.8; #X obj 38 286 0; #X obj 19 306 f; #X obj 295 564 tabwrite~ test; #X msg 19 346 list test 2048 \$1 44100 0; #X msg 313 305 read -resize \$1 test; #X text 44 194 analyse; #X obj 19 372 sigmund~ -t -npts 2048 -npeak 100 tracks; #X text 243 235 (try it with non-regular signals as well); #X text 23 12 Sigmund~ track analysis bug; #X text 19 34 1 - do one analysis by clicking the green bang. Save the results in a spreadsheet or similar \; 2 - do another analysis \, and compare the results with the first one. There will be lots of differences \; 3 - any further analysis results will match the 2nd analysis (with very few deviations). These results won't be correct \, as after the 1st analysis many lower frequencies will be ignored - this is noticed in a patch such as doc4.data.structures14.partialtracer.pd ; #X text 19 144 The only way to get another correct analysis is to reset sigmund~ by editing it. The results of different analysis will match 100% \, and will have all frequencies.; #X connect 2 0 19 0; #X connect 3 0 7 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 2 0; #X connect 5 0 6 0; #X connect 6 0 19 0; #X connect 8 0 18 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X connect 10 1 17 0; #X connect 11 0 10 0; #X connect 13 0 21 0; #X connect 14 0 13 0; #X connect 15 0 20 0; #X connect 15 1 16 0; #X connect 16 0 18 1; #X connect 17 0 18 1; #X connect 18 0 15 0; #X connect 20 0 23 0; #X connect 21 0 12 0; #X connect 23 0 0 0; ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] sigmund~ analysis issue
Hello list, I'm modernizing the patch doc\4.data.structures\14.partialtracer.pd, and ran into a strange issue: when a sample is loaded and an analysis is made, everything is ok. But, when a 2nd analysis is made, the partials are much higher, and the resynthesis isn't as good. As example, here are the first 2 frames of sigmund's output, analysing the bell.aiff sound. It's also strange that since the sound is stored in a table, the results are different. The parameters haven't been changed after the first run. The only way I find to get good results is by resetting sigmund on edit mode, or restarting the patch. 1ST RUN (OK) t: 0 141.298 0.137147 1 t: 1 385.345 0.0581239 1 t: 2 707.462 0.04726 1 t: 3 269.206 0.0434673 1 t: 4 364.112 0.0225979 1 t: 5 595.773 0.025954 1 t: 6 1084.57 0.0182461 1 t: 7 63.9805 0.015155 1 t: 8 541.068 0.0129506 1 t: 9 1049.86 0.00814875 1 t: 10 832.513 0.00709686 1 t: 11 215.332 0.00335958 1 t: 12 944.526 0.00692402 1 t: 13 1310.13 0.00669407 1 t: 14 1895.28 0.00548327 1 t: 15 888.046 0.00420553 1 t: 16 456.796 0.00381943 1 t: 17 1183.88 0.0032292 1 t: 18 757.497 0.00395218 1 t: 19 1554.4 0.00269764 1 t: 20 1290.07 0.00354588 1 t: 21 1670.57 0.0023464 1 t: 22 1414.85 0.00239386 1 t: 23 2099.85 0.00248014 1 t: 24 1225.45 0.00165636 1 t: 25 2249.42 0.00192396 1 t: 26 2127.87 0.00166951 1 t: 27 2737.03 0.00157576 1 t: 28 1770.02 0.00134567 1 t: 29 2462.81 0.00138555 1 t: 30 1473.12 0.00158225 1 t: 31 1991.32 0.00150557 1 t: 32 2505.45 0.00118963 1 t: 33 3522.37 0.00128237 1 t: 34 1400.38 0.00170432 1 t: 35 2024.19 0.00113305 1 t: 36 2983.94 0.000941453 1 t: 37 3075.74 0.00101321 1 t: 38 3286.13 0.000883695 1 t: 39 2531.29 0.000845063 1 t: 0 138.628 0.135288 0 t: 1 386.632 0.0500026 0 t: 2 705.62 0.0487652 0 t: 3 258.881 0.0428605 0 t: 4 296.177 0.0105696 1 t: 5 605.138 0.0219934 0 t: 6 1082.22 0.0180366 0 t: 7 57.4144 0.00979881 0 t: 8 535.631 0.00879348 0 t: 9 952.848 0.00944249 1 t: 10 830.594 0.00784354 0 t: 11 1630.66 0.000687276 1 t: 12 955.149 0.00600927 0 t: 13 1303.32 0.00753062 0 t: 14 1893.23 0.0056183 0 t: 15 878.553 0.00487427 0 t: 16 466.142 0.00383666 0 t: 17 1186.99 0.0048419 0 t: 18 751.237 0.0064956 0 t: 19 1547.86 0.00369452 0 t: 20 2211.92 0.000763845 1 t: 21 1665.65 0.00158778 0 t: 22 1439.33 0.00140849 0 t: 23 2108.29 0.00329683 0 t: 24 1834.18 0.000674865 1 t: 25 2250.51 0.00168626 0 t: 26 2810.52 0.000731613 1 t: 27 2738.07 0.0014678 0 t: 28 1765.87 0.00197579 0 t: 29 2459.03 0.00111085 0 t: 30 1490.06 0.00153197 0 t: 31 1981.18 0.00127681 0 t: 32 2496.56 0.00104289 0 t: 33 3523.31 0.000949688 0 t: 34 1399.56 0.00239812 0 t: 35 2022.71 0.00165475 0 t: 36 2983.59 0.00090797 0 t: 37 3075.81 0.00103291 0 t: 38 3284.22 0.000780804 0 t: 39 2368.94 0.000667367 1 2ND RUN (partials are higher) t: 0 456.796 0.00381943 0 t: 1 944.526 0.00692402 0 t: 2 364.112 0.0225979 0 t: 3 215.332 0.00335958 1 t: 4 385.345 0.0581239 0 t: 5 1290.07 0.00354588 0 t: 6 1991.32 0.00150557 0 t: 7 269.206 0.0434673 0 t: 8 888.046 0.00420553 1 t: 9 141.298 0.137147 0 t: 10 63.9805 0.015155 0 t: 11 757.497 0.00395218 0 t: 12 1084.57 0.0182461 0 t: 13 595.773 0.025954 0 t: 14 1895.28 0.00548327 0 t: 15 1049.86 0.00814875 0 t: 16 707.462 0.04726 0 t: 17 1225.45 0.00165636 1 t: 18 2462.81 0.00138555 0 t: 19 2737.03 0.00157576 1 t: 20 541.068 0.0129506 0 t: 21 832.513 0.00709686 0 t: 22 1473.12 0.00158225 0 t: 23 1310.13 0.00669407 0 t: 24 1770.02 0.00134567 1 t: 25 2531.29 0.000845063 0 t: 26 1414.85 0.00239386 0 t: 27 2024.19 0.00113305 0 t: 28 2505.45 0.00118963 1 t: 29 3522.37 0.00128237 1 t: 30 2099.85 0.00248014 0 t: 31 1670.57 0.0023464 0 t: 32 1400.38 0.00170432 1 t: 33 1554.4 0.00269764 0 t: 34 2127.87 0.00166951 0 t: 35 2983.94 0.000941453 1 t: 36 2249.42 0.00192396 0 t: 37 1183.88 0.0032292 0 t: 38 3075.74 0.00101321 1 t: 39 3286.13 0.000883695 1 t: 0 466.142 0.00383666 0 t: 1 955.149 0.00600927 0 t: 2 296.177 0.0105696 1 t: 3 952.848 0.00944249 1 t: 4 386.632 0.0500026 0 t: 5 1630.66 0.000687276 1 t: 6 1981.18 0.00127681 0 t: 7 258.881 0.0428605 0 t: 8 878.553 0.00487427 0 t: 9 138.628 0.135288 0 t: 10 57.4144 0.00979881 0 t: 11 751.237 0.0064956 0 t: 12 1082.22 0.0180366 0 t: 13 605.138 0.0219934 0 t: 14 1893.23 0.0056183 0 t: 15 2211.92 0.000763845 1 t: 16 705.62 0.0487652 0 t: 17 1834.18 0.000674865 1 t: 18 2459.03 0.00111085 0 t: 19 2738.07 0.0014678 0 t: 20 535.631 0.00879348 0 t: 21 830.594 0.00784354 0 t: 22 1490.06 0.00153197 0 t: 23 1303.32 0.00753062 0 t: 24 1765.87 0.00197579 0 t: 25 2810.52 0.000731613 1 t: 26 1439.33 0.00140849 0 t: 27 2022.71 0.00165475 0 t: 28 2496.56 0.00104289 0 t: 29 3523.31 0.000949688 0 t: 30 2108.29 0.00329683 0 t: 31 1665.65 0.00158778 0 t: 32 1399.56 0.00239812 0 t: 33 1547.86 0.00369452 0 t: 34 2368.94 0.000667367 1 t: 35 2983.59 0.00090797 0 t: 36 2250.51 0.00168626 0 t: 37 1186.99 0.0048419 0 t: 38 3075.81 0.00103291 0 t: 39 3284.22 0.000780804 0 ___ Pd-list@lists.iem.at mailing list UNSUBSCRI
Re: [PD] [sigmund~] table analysis crash
Cool. Merged it. M On Sat, Jun 01, 2019 at 04:01:06PM +0200, Christof Ressi wrote: > thanks for reporting! fixed here: > https://github.com/pure-data/pure-data/pull/646 > > > Gesendet:??Samstag, 01. Juni 2019 um 15:12 Uhr > Von:??"William Brent" > An:??Pd-List > Betreff:??[PD] [sigmund~] table analysis crash > > Hi all, > I just came across a crash with [sigmund~ -t]. I triggered it by accidentally > feeding sigmund~ an analysis request with a samplerate of 0. It doesn't > happen with 32bit Pd, only 64bit. I'm using: > ?? > Pd-0.49-1 > Mac OS 10.13.6 > ?? > I've attached a simple patch to demonstrate. > ?? > ?? > ??-- > William Brent > www.williambrent.com[http://www.williambrent.com] > > ???Great minds flock together??? > Conflations: conversational idiom for the 21st century > > www.conflations.com[http://www.conflations.com]___ > Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] > > > > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sigmund~] table analysis crash
note the word "accidentally" ;-) Gesendet: Samstag, 01. Juni 2019 um 18:30 Uhr Von: "Alexandre Torres Porres" An: "William Brent" Cc: Pd-List Betreff: Re: [PD] [sigmund~] table analysis crash why would you need a samplerate of 0? Em sáb, 1 de jun de 2019 às 10:15, William Brent <william.br...@gmail.com> escreveu: Hi all, I just came across a crash with [sigmund~ -t]. I triggered it by accidentally feeding sigmund~ an analysis request with a samplerate of 0. It doesn't happen with 32bit Pd, only 64bit. I'm using: Pd-0.49-1 Mac OS 10.13.6 I've attached a simple patch to demonstrate. -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sigmund~] table analysis crash
why would you need a samplerate of 0? Em sáb, 1 de jun de 2019 às 10:15, William Brent escreveu: > Hi all, > I just came across a crash with [sigmund~ -t]. I triggered it by > accidentally feeding sigmund~ an analysis request with a samplerate of 0. > It doesn't happen with 32bit Pd, only 64bit. I'm using: > > Pd-0.49-1 > Mac OS 10.13.6 > > I've attached a simple patch to demonstrate. > > > > -- > William Brent > www.williambrent.com > > “Great minds flock together” > Conflations: conversational idiom for the 21st century > > www.conflations.com > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [sigmund~] table analysis crash
thanks for reporting! fixed here: https://github.com/pure-data/pure-data/pull/646 Gesendet: Samstag, 01. Juni 2019 um 15:12 Uhr Von: "William Brent" An: Pd-List Betreff: [PD] [sigmund~] table analysis crash Hi all, I just came across a crash with [sigmund~ -t]. I triggered it by accidentally feeding sigmund~ an analysis request with a samplerate of 0. It doesn't happen with 32bit Pd, only 64bit. I'm using: Pd-0.49-1 Mac OS 10.13.6 I've attached a simple patch to demonstrate. -- William Brent www.williambrent.com[http://www.williambrent.com] “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com[http://www.conflations.com]___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [sigmund~] table analysis crash
Hi all, I just came across a crash with [sigmund~ -t]. I triggered it by accidentally feeding sigmund~ an analysis request with a samplerate of 0. It doesn't happen with 32bit Pd, only 64bit. I'm using: Pd-0.49-1 Mac OS 10.13.6 I've attached a simple patch to demonstrate. -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com sigmundCrash64.pd Description: Binary data ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~
* Matt Davey [2019-01-21 15:15]: > FINALLY got the [sigmund~] analysis joke (facepalm) > > honestly, have been wondering for a long time what that was all about... Congrats! Would you give a hint about that joke? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~
* Peter P. [2019-01-21 15:39]: > * Matt Davey [2019-01-21 15:15]: > > FINALLY got the [sigmund~] analysis joke (facepalm) > > > > honestly, have been wondering for a long time what that was all about... > Congrats! Would you give a hint about that joke? Oh, you mean the name of the object? You should check out its partner object [martha~] as well! ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] sigmund~
FINALLY got the [sigmund~] analysis joke (facepalm) honestly, have been wondering for a long time what that was all about... ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~
oh, and an actual question: does sigmund~ use the same pitch detection algorithm as fiddle? For a guitar tuner that just needs to detect the most prominent frequency, is there a particular advantage of using one over the other? ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Sigmund+reblocking
you're welcome! > Do you mean lower than 64? Generally. The idea about calculating audio samples in blocks is that you only have to call the dsp perform routines every N samples. The lower the block size, the more often the routine gets called, thus CPU usage rises. Sometimes you want to increase the blocksize above 64 for mere effiency reasons (in opposition to, say, FFT subpatches where it is often needed). An example for this is upsampling: You could do [block~ 64 0 4] (upsampling by a factor of 4), but it's generally a good idea to increase the blocksize accordingly - in this case [block~ 256 0 4] - to save some CPU load.*) Christof *) Also, some objects like [block~] or [vline~] don't work correctly below the rate of Pd's scheduler - which is 64 samples @ 44100 Hz or 128 samples @ 88200 Hz and so on. Another reason to increase the blocksize for upsampling. > Gesendet: Sonntag, 16. Oktober 2016 um 15:32 Uhr > Von: "Fede Camara Halac" > An: "Christof Ressi" > Cc: pd-list@lists.iem.at > Betreff: Re: Aw: [PD] Sigmund+reblocking > > Hi Christof, > > Thanks for this > > for a 1 sample delay you can also do [rzero_rev~ 0] or - if you use zexy - > > [z~ 1]. > > I suspected this about sigmund but I was not sure > > doesn't really care about the actual blocksize of the patch it sits in. > > About blocksize and CPU: > > but note that a lower blocksize creates higher CPU usage. > Do you mean lower than 64? > > > why do you want to delay the signal by one sample before going into > > sigmund~ in the first place? > there had to be 1 samp delay between the index of tabread4 and the analysis > of its output. I'm thinking now in other ways of doing this! > > Again, this was just my idea and I guess overnight patching does strange > things to you. > > Thanks again! > > Fede > > fedecamarahalac.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Sigmund+reblocking
Hi Christof, Thanks for this > for a 1 sample delay you can also do [rzero_rev~ 0] or - if you use zexy - > [z~ 1]. I suspected this about sigmund but I was not sure > doesn't really care about the actual blocksize of the patch it sits in. About blocksize and CPU: > but note that a lower blocksize creates higher CPU usage. Do you mean lower than 64? > why do you want to delay the signal by one sample before going into sigmund~ > in the first place? there had to be 1 samp delay between the index of tabread4 and the analysis of its output. I'm thinking now in other ways of doing this! Again, this was just my idea and I guess overnight patching does strange things to you. Thanks again! Fede fedecamarahalac.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Sigmund+reblocking
reblocking to a *lower* blocksize doesn't make a delay. but why don't you use a delay line ;-)? for a 1 sample delay you can also do [rzero_rev~ 0] or - if you use zexy - [z~ 1]. regarding [sigmund~]: since the object uses FFT inside, it just collects enough samples for the given window size (default 1024) and doesn't really care about the actual blocksize of the patch it sits in. but note that a lower blocksize creates higher CPU usage. why do you want to delay the signal by one sample before going into sigmund~ in the first place? Gesendet: Sonntag, 16. Oktober 2016 um 07:02 Uhr Von: "Fede Camara Halac" An: pd-list@lists.iem.at Betreff: [PD] Sigmund+reblocking Hi all, Would reblocking a subpatch have any effect on [sigmund~]? Below is what I did. My idea was to delay the signal by one sample before going to sigmund. This is certainly not what is happening, though, but sigmund still works for all 10 tracks as if no reblocking had been made. Is sigmund overriding the block object and reblocking to 128? [block~ 1] [inlet~] | [sigmund~ -hop 1024 -npeak 10 tracks] | [outlet~] Thanks! Fede fedecamarahalac.com[http://fedecamarahalac.com] ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Sigmund+reblocking
Hi all, Would reblocking a subpatch have any effect on [sigmund~]? Below is what I did. My idea was to delay the signal by one sample before going to sigmund. This is certainly not what is happening, though, but sigmund still works for all 10 tracks as if no reblocking had been made. Is sigmund overriding the block object and reblocking to 128? [block~ 1] [inlet~] | [sigmund~ -hop 1024 -npeak 10 tracks] | [outlet~] Thanks! Fede fedecamarahalac.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~ help file segfaults
Hi Miller, I did your suggestion with gdb & everything works. No crash. archlinux package crashes. building commands for archlinux: ./autogen.sh ./configure --enable-jack make uh? 2015-04-04 7:05 GMT+02:00 Miller Puckette : > Well, I tried some more but still can't make it crash over here... > > If you're interested in pursuing this, perhaps you can get me a stack > backtrace from your machine (unpack source; cd pd/src; > make -f makefile.gnu MORECFLAGS=-g; gdb ../bin/pd and from within > gdb, "run -nrt" and make it crash :) > > cheers > Miller > > On Fri, Apr 03, 2015 at 05:49:51PM +0200, Fero Kiraly wrote: > > Hi Miller, > > > > - 64bit Linux (archlinux) > > > > Also to crash Pd you just have to > > start Pd, start DSP, make a sigmund~ and select help for it, right? YES. > > > > I did a little investigation and problem is somewhere inside [pd > > sinusoid-tracking] - without this subpatch everything works. > > > > thanks > > fero > > > > 2015-04-03 17:42 GMT+02:00 Miller Puckette : > > > > > Hi fero - > > > > > > I can't get this to happen (Fedora 21, 64 bits) - what's your audio > > > setup (jack? etc) and 32 or 64 bit linux? Also to crash Pd you just > have > > > to > > > start Pd, start DSP, make a sigmund~ and select help for it, right? > > > > > > thanks > > > Miller > > > > > > On Fri, Apr 03, 2015 at 05:30:59PM +0200, Fero Kiraly wrote: > > > > Hi dear people. > > > > > > > > pd vanilla 0.46.6 > > > > archlinux > > > > - when audio is ON, opening a [sigmund~] help file, pd crash & > segfaults. > > > > [sigmund~] separately works. only something with help file.. > > > > > > > > Thanks for your work! > > > > > > > > fero > > > > > > > ___ > > > > Pd-list@lists.iem.at mailing list > > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > -- > > Fero Kiraly > > pianist, musician, teacher > > www.ferokiraly.com > > www.cluster-ensemble.com > > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- Fero Kiraly pianist, musician, teacher www.ferokiraly.com www.cluster-ensemble.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~ help file segfaults
Well, I tried some more but still can't make it crash over here... If you're interested in pursuing this, perhaps you can get me a stack backtrace from your machine (unpack source; cd pd/src; make -f makefile.gnu MORECFLAGS=-g; gdb ../bin/pd and from within gdb, "run -nrt" and make it crash :) cheers Miller On Fri, Apr 03, 2015 at 05:49:51PM +0200, Fero Kiraly wrote: > Hi Miller, > > - 64bit Linux (archlinux) > > Also to crash Pd you just have to > start Pd, start DSP, make a sigmund~ and select help for it, right? YES. > > I did a little investigation and problem is somewhere inside [pd > sinusoid-tracking] - without this subpatch everything works. > > thanks > fero > > 2015-04-03 17:42 GMT+02:00 Miller Puckette : > > > Hi fero - > > > > I can't get this to happen (Fedora 21, 64 bits) - what's your audio > > setup (jack? etc) and 32 or 64 bit linux? Also to crash Pd you just have > > to > > start Pd, start DSP, make a sigmund~ and select help for it, right? > > > > thanks > > Miller > > > > On Fri, Apr 03, 2015 at 05:30:59PM +0200, Fero Kiraly wrote: > > > Hi dear people. > > > > > > pd vanilla 0.46.6 > > > archlinux > > > - when audio is ON, opening a [sigmund~] help file, pd crash & segfaults. > > > [sigmund~] separately works. only something with help file.. > > > > > > Thanks for your work! > > > > > > fero > > > > > ___ > > > Pd-list@lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > > > -- > Fero Kiraly > pianist, musician, teacher > www.ferokiraly.com > www.cluster-ensemble.com > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~ help file segfaults
Hi Miller, - 64bit Linux (archlinux) Also to crash Pd you just have to start Pd, start DSP, make a sigmund~ and select help for it, right? YES. I did a little investigation and problem is somewhere inside [pd sinusoid-tracking] - without this subpatch everything works. thanks fero 2015-04-03 17:42 GMT+02:00 Miller Puckette : > Hi fero - > > I can't get this to happen (Fedora 21, 64 bits) - what's your audio > setup (jack? etc) and 32 or 64 bit linux? Also to crash Pd you just have > to > start Pd, start DSP, make a sigmund~ and select help for it, right? > > thanks > Miller > > On Fri, Apr 03, 2015 at 05:30:59PM +0200, Fero Kiraly wrote: > > Hi dear people. > > > > pd vanilla 0.46.6 > > archlinux > > - when audio is ON, opening a [sigmund~] help file, pd crash & segfaults. > > [sigmund~] separately works. only something with help file.. > > > > Thanks for your work! > > > > fero > > > ___ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > -- Fero Kiraly pianist, musician, teacher www.ferokiraly.com www.cluster-ensemble.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~ help file segfaults
Hi fero - I can't get this to happen (Fedora 21, 64 bits) - what's your audio setup (jack? etc) and 32 or 64 bit linux? Also to crash Pd you just have to start Pd, start DSP, make a sigmund~ and select help for it, right? thanks Miller On Fri, Apr 03, 2015 at 05:30:59PM +0200, Fero Kiraly wrote: > Hi dear people. > > pd vanilla 0.46.6 > archlinux > - when audio is ON, opening a [sigmund~] help file, pd crash & segfaults. > [sigmund~] separately works. only something with help file.. > > Thanks for your work! > > fero > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] sigmund~ help file segfaults
Hi dear people. pd vanilla 0.46.6 archlinux - when audio is ON, opening a [sigmund~] help file, pd crash & segfaults. [sigmund~] separately works. only something with help file.. Thanks for your work! fero ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
