Hello List.
I'm on Pd 0.49 on linux ubuntustudio lsb_release -a shows Ubuntu 18.04.2 LTS
short version: open the zip folder and start "UsandoFftHanning.pd" and try to click on any set message that goes to block~. Here it crashes everything.
long version: I was trying to create simple abstractions that could help me creating a hanning window and using simple fft to show spectrum in a parent patch. I was experiencing problems with tabwrite~ + metro 100 because it was not writing in the start of array1 (like dc frequency was 3/4 in the array instead of the start of the array), so i suspected that maybe if i used [metro 1028 1 samp] it would work. It doesn't help... So i put a [block~ 1024] and voila it worked.
But this is strange because i wanted to see it at normal block, since i want to use dac~ and etc... then i created a bunch of [set( messages to control block to see where it works fine or not.
Here it started the bug. whenever a click on wherever set message, pd crashes. if i try to close the patch it crashes, if i try to open any abstraction it crashes, if i try to stop metro it crashes... it literally crashes with any action i believe... can someone test if opening UsandoFftHanning.pd does the same thing? i don't know how to report this bug since i don't know what makes it crash...
i just noticed that i write the numbers all wrong in the e-mail, so i go to check the patch and indeed block~ is 1028 what doesn't make sense... maybe he is the culprit, but it is strange because pd allowed me to create that object, and after that it started to crash. May someone test this, and then i write to github?
Em qua, 8 de mai de 2019 às 12:55, José de Abreu abreubacelar@gmail.com escreveu:
Hello List.
I'm on Pd 0.49 on linux ubuntustudio lsb_release -a shows Ubuntu 18.04.2 LTS
short version: open the zip folder and start "UsandoFftHanning.pd" and try to click on any set message that goes to block~. Here it crashes everything.
long version: I was trying to create simple abstractions that could help me creating a hanning window and using simple fft to show spectrum in a parent patch. I was experiencing problems with tabwrite~ + metro 100 because it was not writing in the start of array1 (like dc frequency was 3/4 in the array instead of the start of the array), so i suspected that maybe if i used [metro 1028 1 samp] it would work. It doesn't help... So i put a [block~ 1024] and voila it worked.
But this is strange because i wanted to see it at normal block, since i want to use dac~ and etc... then i created a bunch of [set( messages to control block to see where it works fine or not.
Here it started the bug. whenever a click on wherever set message, pd crashes. if i try to close the patch it crashes, if i try to open any abstraction it crashes, if i try to stop metro it crashes... it literally crashes with any action i believe... can someone test if opening UsandoFftHanning.pd does the same thing? i don't know how to report this bug since i don't know what makes it crash...
when I run your patch in a debugger, clicking the [set( always crashes Pd immediately, so there is definitely a bug.
but regarding you use case, I wouldn't use [block~] at all to control the update rate! instead, could use [bang~] *inside* your FFT abstraction which signalizes the start of a FFT window. if you don't want to write to the display every FFT window, you can use a [spigot] which you open only every N milliseconds and then close immediately. note that you need to do some additional latency compensation because the audio output of a blocked subpatch of blocksize 1024 is delayed by 960 samples relative to a parent patch of block size 64 (the default). see attached patch.
Christof
Gesendet: Mittwoch, 08. Mai 2019 um 18:01 Uhr Von: "José de Abreu" abreubacelar@gmail.com An: "PD list" pd-list@lists.iem.at Betreff: Re: [PD] Strange Bug Crashing Pd (block + abstractions + fft)
i just noticed that i write the numbers all wrong in the e-mail, so i go to check the patch and indeed block~ is 1028 what doesn't make sense... maybe he is the culprit, but it is strange because pd allowed me to create that object, and after that it started to crash. May someone test this, and then i write to github?
Em qua, 8 de mai de 2019 às 12:55, José de Abreu <abreubacelar@gmail.com[mailto:abreubacelar@gmail.com]> escreveu:
Hello List. I'm on Pd 0.49 on linux ubuntustudio lsb_release -a shows Ubuntu 18.04.2 LTS short version: open the zip folder and start "UsandoFftHanning.pd" and try to click on any set message that goes to block~. Here it crashes everything. long version: I was trying to create simple abstractions that could help me creating a hanning window and using simple fft to show spectrum in a parent patch. I was experiencing problems with tabwrite~ + metro 100 because it was not writing in the start of array1 (like dc frequency was 3/4 in the array instead of the start of the array), so i suspected that maybe if i used [metro 1028 1 samp] it would work. It doesn't help... So i put a [block~ 1024] and voila it worked. But this is strange because i wanted to see it at normal block, since i want to use dac~ and etc... then i created a bunch of [set( messages to control block to see where it works fine or not. Here it started the bug. whenever a click on wherever set message, pd crashes. if i try to close the patch it crashes, if i try to open any abstraction it crashes, if i try to stop metro it crashes... it literally crashes with any action i believe... can someone test if opening UsandoFftHanning.pd does the same thing? i don't know how to report this bug since i don't know what makes it crash..._______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Btw, if you get rid of the overlap, things get much easier since you can just bang a [tabwrite~] *inside* the fft subpatch at the desired rate with a metro. I'm not sure if the overlap actually buys you anything if you only want to display.
Gesendet: Mittwoch, 08. Mai 2019 um 18:50 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "José de Abreu" abreubacelar@gmail.com Cc: "PD list" pd-list@lists.iem.at Betreff: Re: [PD] Strange Bug Crashing Pd (block + abstractions + fft)
when I run your patch in a debugger, clicking the [set( always crashes Pd immediately, so there is definitely a bug.
but regarding you use case, I wouldn't use [block~] at all to control the update rate! instead, could use [bang~] *inside* your FFT abstraction which signalizes the start of a FFT window. if you don't want to write to the display every FFT window, you can use a [spigot] which you open only every N milliseconds and then close immediately. note that you need to do some additional latency compensation because the audio output of a blocked subpatch of blocksize 1024 is delayed by 960 samples relative to a parent patch of block size 64 (the default). see attached patch.
Christof
Gesendet: Mittwoch, 08. Mai 2019 um 18:01 Uhr Von: "José de Abreu" abreubacelar@gmail.com An: "PD list" pd-list@lists.iem.at Betreff: Re: [PD] Strange Bug Crashing Pd (block + abstractions + fft)
i just noticed that i write the numbers all wrong in the e-mail, so i go to check the patch and indeed block~ is 1028 what doesn't make sense... maybe he is the culprit, but it is strange because pd allowed me to create that object, and after that it started to crash. May someone test this, and then i write to github?
Em qua, 8 de mai de 2019 às 12:55, José de Abreu <abreubacelar@gmail.com[mailto:abreubacelar@gmail.com]> escreveu:
Hello List. I'm on Pd 0.49 on linux ubuntustudio lsb_release -a shows Ubuntu 18.04.2 LTS short version: open the zip folder and start "UsandoFftHanning.pd" and try to click on any set message that goes to block~. Here it crashes everything. long version: I was trying to create simple abstractions that could help me creating a hanning window and using simple fft to show spectrum in a parent patch. I was experiencing problems with tabwrite~ + metro 100 because it was not writing in the start of array1 (like dc frequency was 3/4 in the array instead of the start of the array), so i suspected that maybe if i used [metro 1028 1 samp] it would work. It doesn't help... So i put a [block~ 1024] and voila it worked. But this is strange because i wanted to see it at normal block, since i want to use dac~ and etc... then i created a bunch of [set( messages to control block to see where it works fine or not. Here it started the bug. whenever a click on wherever set message, pd crashes. if i try to close the patch it crashes, if i try to open any abstraction it crashes, if i try to stop metro it crashes... it literally crashes with any action i believe... can someone test if opening UsandoFftHanning.pd does the same thing? i don't know how to report this bug since i don't know what makes it crash..._______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
José de Abreu