Hi, > It works for me but there is a delay (32 samples)
you're right! I made a mistake in my testing. So we can really state that the issue arises when the hopsize is smaller than the blocksize of the parent patch. I attached a patch (overlap-issue-explained.pd) to show the problem visually. what happens is that [inlet~] starts to take copies of the same last block. @Miller: is this a limitation by design or a bug that can be fixed? > overlapping should not reduce the block size where does it reduce the block size? regarding debugging I suggest you use [tabwrite~] instead of [print~]. it's much clearer what's going on. > but there is a delay (32 samples) in Pd it's somehow assumed that overlapping is always performed together with reblocking (to a larger blocksize), so you get a delay implicitely, although overlapping itself doesn't introduce a delay. overlapping is mostly (if not always) used in the context of FFT patches where you need reblocking anyway. BTW, there's a situation where our discovery (?) gets very useful for FFT patches - see fft-overlap-hack.pd Christof Gesendet: Mittwoch, 19. Juli 2017 um 10:45 Uhr Von: "Pierre Guillot" <guillotpier...@gmail.com> An: "Christof Ressi" <christof.re...@gmx.at> Cc: pd-list@lists.iem.at Betreff: Re: Re: [PD] DSP cycle - block size & overlapping Hi, 1) I wanted to use [bang~] with [print~] to debug (you can also uses [print~] with higher block sizes but you won't be able to see what happens with overlap and block sizes inferior to 64 samples). And I guess you can always find an application because using smaller block sizes can simplify your approach. I mean it's not necessarily the only solution but it can be useful. 2) It works for me but there is a delay (32 samples) here the patch https://gist.github.com/pierreguillot/908918436e6dcfb27ba413a5da4f8f63. I don't understand why, for you, the block size should be reduced to 32 samples, overlapping should not reduce the block size and I don't really how to do manual overlap with delay line, can you explain it? Just to be clear, for me, overlap should perform something like that (with parent patch [block~ 32 1] & child patch [block~ 64 2]): [ 32 ][ 32 ][ 32 ][ 32 ][ 32 ] [ 64 ][ 64 ][ .. .. ][ 64 ][ 64 ] Cheers, Pierre 2017-07-18 22:24 GMT+02:00 Christof Ressi <christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:1) 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... 2) 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" <guillotpier...@gmail.com[mailto:guillotpier...@gmail.com]> An: "Christof Ressi" <christof.re...@gmx.at[mailto:christof.re...@gmx.at]> Cc: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at] Betreff: Re: [PD] DSP cycle - block size & overlapping Hi Christof, 1) 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.re...@gmx.at[mailto:christof.re...@gmx.at][mailto:christof.re...@gmx.at[mailto:christof.re...@gmx.at]]>: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" <guillotpier...@gmail.com[mailto:guillotpier...@gmail.com][mailto:guillotpier...@gmail.com[mailto:guillotpier...@gmail.com]]> An: pd-list@lists.iem.at[mailto:pd-list@lists.iem.at][mailto: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[https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a][https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a[https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a]] Cheers,Pierre_______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto:Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]][https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list][https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]]]
fft-overlap-hack.pd
Description: Binary data
overlap-issue-explained.pd
Description: Binary data
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
