2016-05-03 23:06 GMT-03:00 Miller Puckette msp@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