[PD] DSP cycle - block size & overlapping

[Christof Ressi]

Hi,

1) unfortunately, all objects using clocks won't work correctly for block sizes smaller than 64, for the very reasons you already mentioned. a possible workaround is to send bangs from the parent canvas. there you can use a fast [metro] and sync it with [bang~].

2) again, this is a clock issue. the hop size mustn't be smaller than 64 samples, e.g. for overlap 4 you need at least a blocksize of 256. what happens in your patch with [block 64 2 1] is that [inlet~] fetches the same block twice (instead of two blocks 32 samples apart) and then performs the overlap add. 

therefore with

-1  1  1  1  1  1  1  1  
1  1  1  1  1  1  1  1  
1  1  1  1  1  1  1  1  
1  1  1  1  1  1  1  1  
1  -1  -1  -1  -1  -1  -1  -1  
-1  -1  -1  -1  -1  -1  -1  -1  
-1  -1  -1  -1  -1  -1  -1  -1  
-1  -1  -1  -1  -1  -1  -1  -1  

you get all zeros.

and with

0  1  1  1  1  1  1  1  
1  1  1  1  1  1  1  1  
1  1  1  1  1  1  1  1  
1  1  1  1  1  1  1  1  
1  0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  
0  0  0  0  0  0  0  0  

you get all ones.

Christof

 
 
 

Gesendet: Dienstag, 18. Juli 2017 um 17:14 Uhr
Von: "Pierre Guillot" <guillotpierre6 at gmail.com>
An: pd-list at lists.iem.at
Betreff: [PD] DSP cycle - block size & overlapping

Hi all,
 
I'm experimenting with different block sizes and overlapping factors for subpatches and I encountered 2 issues (or perhaps my mind is completely scrambled, tell me...):
 
1st: the output of [bang~] is limited by the default block size (64 samples). I understand why it works like that - the DSP method of [bang~] uses clock_delay() and the clocks frequencies are limited by the main DSP cycle - and that  avoiding the use of clocks can break the sequential behavior (signal-message). But I think it's strange. Do you think that we can find a way to use [bang~] with smaller block sizes than 64? If not, shouldn't we add something in the help file (it took me a while to figure out this limitation)?
 

2nd: I don't really figure out how the overlapping is performed. Following the [block~]'s help file and I03.resynthesis from the audio examples, I understand that with a block size N and an overlapping factor O, the patch computes blocks of N samples at intervals of N/O samples.
Now, I suppose if the patch has an [inlet~] that directly feeds an [outlet~] the resulting signal would be the input signal multiplied by O. Considering a square wave (between 0 & 1) with a period of N for the input signal and an overlapping factor of 2, I supposed that the resulting signal would also be a square wave multiplied by 2 (between 0 & 2) with the same period. But the resulting signal is a unitary signal of 1, like if the 2nd overlapping block has been shifted by N/2 and is now synchronized with the 1st one. I guess there is something obvious that I don't understand but if anyone can help me I would be very grateful!
 
Here a patch that describes the 2nd problem: https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a
 
Cheers,
Pierre_______________________________________________ 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]