the question I just asked myself is, how would you use these bangs? since all clock timeouts will still be handled every 64 samples I can't think of any real applications...
in your case, the blocks do have 64 samples, it's just that it's two times the same block instead of two blocks 32 samples apart because [inlet~] can't handle hop sizes less than 64 samples. therefore a [block~ 32 1] in the parent patch won't help either (I tried it). but you can always do manual overlap and add with delay lines.
Gesendet: Dienstag, 18. Juli 2017 um 19:11 Uhr Von: "Pierre Guillot" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list@lists.iem.at Betreff: Re: [PD] DSP cycle - block size & overlapping
Hi Christof,
- So I guess it should be documented. Can you explain the workaround. The idea would be for example to generate a bang every cycles of 32 samples.
2) In fact, with [block~ 64 2 1], I don't expect to have two blocks of 32 samples but 2 blocks of 64 samples (shifted by 32 samples). But I guess I understand the limitation (perhaps it should also be documented or perhaps I'm missed it?). So in fact the hope size must be at least the block size of the parent patch (that seems logic) so if I want to use [block~ 64 2] I need my parent patch to have [block~ 32 1] (and that implies a delay of 32 samples?). I'm right? Thanks! 2017-07-18 18:29 GMT+02:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:Hi,
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~].
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@gmail.com[mailto:guillotpierre6@gmail.com]> An: pd-list@lists.iem.at[mailto:pd-list@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%5Bhtt...] Cheers,Pierre_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]