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" <[email protected]>
> An: "José de Abreu" <[email protected]>
> Cc: "PD list" <[email protected]>
> 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" <[email protected]>
> An: "PD list" <[email protected]>
> 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 
> <[email protected][mailto:[email protected]]> 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..._______________________________________________ [email protected] 
> mailing list UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]_______________________________________________
> [email protected] mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>



_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to