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@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@gmail.com *An:* Pd-List pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list