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
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 An: 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 Cheers, Pierre_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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.
- 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:
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 An: 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
Cheers, Pierre_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps:// lists.puredata.info/listinfo/pd-list]
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...]]
Hi,
- 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 christof.ressi@gmx.at:
- 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.
- 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/5e775b39860330739e3efbb6adb8ad 1a[https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a]
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[https://lists.puredata.info/listinfo/ pd-list][https://lists.puredata.info/listinfo/pd- list[https://lists.puredata.info/listinfo/pd-list]]
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" guillotpierre6@gmail.com An: "Christof Ressi" christof.ressi@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.ressi@gmx.at[mailto:christof.ressi@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...
- 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[mailto:guillotpierre6@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]> Cc: pd-list@lists.iem.at[mailto: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][mailto: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][mailto:guillotpierre6@gmail.com[mailto:guillotpierre6@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%5Bhtt...]] 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%5Bhttps://lists.puredata.info/l...]]]
-
Christof Ressi -
Pierre Guillot