[PD] delay with fft / block size with overlap

[Alexandre Torres Porres]

yeah, the spectral delay deal I already have an example patch that works,
but for this other patch I'm working on, I really need the delay time to
fall in between hop sizes, so I just can't really do it then, and I think I
understand why now.

thanks

Em sáb, 3 de ago de 2019 às 19:43, Christof Ressi <christof.ressi at gmx.at>
escreveu:

> Hi,
>
> when you have a [delwrite~] in a subpatch with overlap, you have to make
> sure that the delay time for [delread~] is rounded down to the hopsize in
> ms, otherwise you will read parts of two non-consecutive blocks of audio
> and get glitchy results. Here's what happens:
>
> [block~ 8 4] // for the sake of simplicity
>
> blocksize: 8, overlap: 4, hopsize: 2
>
> input signal: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
>
> [delwrite~] fills the delay line for every window:
>
> window1: 0, 1, 2, 3, 4, 5, 6, 7
> window2: 2, 3, 4, 5, 6, 7, 8, 9
> window3: 4, 5, 6, 7, 8, 9, 10, 11
> window4: 6, 7, 8, 9, 10, 11, 12, 13
>
> after 8 samples of input, the delay line will actually contain 8 * 4 = 32
> samples:
>
> 0, 1, 2, 3, 4, 5, 6, 7 | 2, 3, 4, 5, 6, 7, 8, 9 | 4, 5, 6, 7, 8, 9, 10, 11
> | 6, 7, 8, 9, 10, 11, 12, 13
>
> as you can see, the delay time *in samples* for [delread~] must be a
> multiple of 8 (= blocksize) to avoid discontinuities. when [delread~]
> converts from ms to samples, it takes the overlap into account, so you can
> use a multiple of the *hopsize in ms*.
>
> As you might have noticed, with 4x overlap the delay line needs 4x more
> space than usual. Luckily, [delwrite~] also accounts for the overlap when
> resizing the delay line, so for 4x overlap [delwrite~ 1000] will actually
> allocate 1000 * 44.1 * 4 = 176,400 samples (+ a few extra samples).
>
> Attached you'll find a modified version of your test patch with the
> glitches removed and an example for a spectral delay. Enjoy!
>
> Christof
>
> *Gesendet:* Freitag, 02. August 2019 um 07:46 Uhr
> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
> *An:* Pd-List <pd-list at lists.iem.at>
> *Betreff:* [PD] delay with fft / block size with overlap
> Hi, I'm trying to make sense of how delread/delwrite work in a fft
> subpatch.
>
> So, I have attached a test patch, why does it sound so bad? All I'm trying
> to do here is delay the sound input before it gets analyzed/ressynthesized.
> This is not my ultimate goal so I don't really need to do what I'm doing
> here, but I am exploring delays in spectral patches so I need to figure a
> few things out.
>
> thanks
> _______________________________________________ Pd-list at lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190803/9e2e4a6e/attachment.html>