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 <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 <[email protected]>: > 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" <[email protected]> > An: "Christof Ressi" <[email protected]> > Cc: [email protected] > 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 <[email protected][mailto: > [email protected]]>: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" <[email protected][mailto: > [email protected]]> > An: [email protected][mailto:[email protected]] > 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/5e775b39860330739e3efbb6adb8ad > 1a[https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a] > > Cheers,Pierre_______________________________________________ > [email protected][mailto:[email protected]] 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]] >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
