[PD] Delay Bug still buggy in 0.47-0

[Alexandre Torres Porres]

2016-05-03 23:06 GMT-03:00 Miller Puckette <msp at ucsd.edu>:

> OK... I think this is now fixed (just hoping it doesn't make for new
> bugs :)
>

Howdy Miller, I'm testing the new 0.47 version and I see that the bug is
"partially" fixed. I had sent 2 patches describing the bugs and how we
couldn't reach the actual maximum specified delay length. One of these
patches I had sent, the one with [delread~] and a block size of 64 samples
is indeed ok now, but the other one, with vd~ and a block of 2048 and an
overlap of 4 still behaves badly in the exact same way.

So apparently there's more to it when it comes to different block sizes.
And I have some patches where I use delay for spectral processing, so this
ruins everything as I'm using block sizes longer than 64...

We have actually discussed these issues before on this list under different
(but related) threads. I was browsing through the discussion history to see
what else i could find. I found this patch under a thread started by
Christof Ressi ("[PD] [vd~] VS [delread~] - different delay limit!"). The
patch was showing how both objects had different maximum limits. This is in
fact fixed in the new release, but I was working more on this patch and
added a few more things to study how things are working and why I was still
getting the same problems.

It turns out that is seem the delay size is always hard coded to a maximum
block size of 64. If you have block sizes smaller than 64, it is fine, the
maximum delay line is indeed the amount specified. But if you have larger
block sizes, the maximum delay line is actually less than specified.

Let me give you an example with a given sample rate of 44.2khz. A delay
line of 100 ms (4410 samples) and a block size of 4096 (92.8798 ms in
44.1kz) has a maximum delay line of around 378 samples (I'm trying to
calculate this on the patch, but I get a slightly different value).

The 378 samples comes from the whole delay line (4410 samples) minus the
block size (4096) plus a block size of 64 samples (4410 - 4096 + 64 = 378)
 - so, that's about 8.6 ms instead of 100 ms!

An overlap of 4 does upsample the delay line in 4x, so the length goes from
100 ms to 400 ms (and is 17640 samples long instead of the original 4410).
A block size of 4096 will give us a max delay length of about 308.5 ms, so
again the formula is (1760 - 4096 + 64 = 13608 samples [308.5 ms]).

You can check this with the attached patch.

=================================

So, problem is to make the delay line aware of the running block size - and
I have no idea of the challenges involved.

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160509/3e12d2d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delay_block.pd
Type: application/octet-stream
Size: 5701 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160509/3e12d2d2/attachment-0001.obj>