[PD] DSP cycle - block size & overlapping

Pierre Guillot guillotpierre6 at gmail.com
Tue Jul 18 19:11:29 CEST 2017


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>:

> 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>
> An: 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/5e775b39860330739e3efbb6adb8ad1a
>
> Cheers,
> Pierre_______________________________________________ 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]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170718/71e8c56d/attachment-0001.html>


More information about the Pd-list mailing list