[PD] DSP cycle - block size & overlapping

Pierre Guillot guillotpierre6 at gmail.com
Wed Jul 19 10:45:56 CEST 2017


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 <christof.ressi at 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" <guillotpierre6 at gmail.com>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: pd-list at 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.ressi at gmx.at[mailto:
> christof.ressi at 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" <guillotpierre6 at gmail.com[mailto:
> guillotpierre6 at gmail.com]>
> An: pd-list at lists.iem.at[mailto: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/5e775b39860330739e3efbb6adb8ad
> 1a[https://gist.github.com/pierreguillot/5e775b39860330739e3efbb6adb8ad1a]
>
> Cheers,Pierre_______________________________________________
> Pd-list at lists.iem.at[mailto: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][https://lists.puredata.info/listinfo/pd-
> list[https://lists.puredata.info/listinfo/pd-list]]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170719/f4b2ba15/attachment-0001.html>


More information about the Pd-list mailing list