[PD] Strange Bug Crashing Pd (block + abstractions + fft)

[Christof Ressi]

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 at gmail.com>
An: "PD list" <pd-list at 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 at gmail.com[mailto:abreubacelar at 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 at lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crashPdFiles_fix.zip
Type: application/zip
Size: 3796 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190508/0d02fb41/attachment-0001.zip>