#1217 delay size limit bug

[Alexandre Porres]

I have a patch that shows a bug with the maximum time ou can read from a delay line.

From the [vd~] help file, it says

"The delay time is always at least one sample and at most the length of the delay line (specified by the delwrite~)"

So, if the delay is "x" long, we should be able to read from "x" behind in time... but this is not true in the attached patch, so there's a bug the obect.

The patch was originally a phase vocoder, with a block size of 2048 - the maximum size you can read from the delay is then = buffersize - block size + one block of 64 samples.

I fail to see a reason here. If such a limitation happens somehow, maybe the object could be coded in a way that it allows an extra something to make it possible a total length read out.

I thought that maybe the order forcing of delay objects could be something to take into consideration. Well, I did the order forcing and many such tests, but nothing really changed!

please find for info on the attached patch.

[Alexandre Porres]

I'd like to add and emphasize a previous request of adding a "clear" message to the delay line; here's the previous request https://sourceforge.net/p/pure-data/patches/369/

[Alexandre Porres]

As long as we're at it, it'd so cool and great if one could resset the size of the delay line after instantiating the delwrite~ object, with the option to clear the delay line or not - that'd be really swell ;)

[Alexandre Porres]

I'd also like to talk about a "zero length delay", which is kinda related to the thread.

I've been using a delay size of "0" in delwrite~ in a subpatch with a block size of 1 to perform single sample feedback. It works fine. I had assumed then that the minimum delay size was "one block" size, even if you inserted a smaller buffer size or even zero. By the way, that seems to me like a clever design. After all, you need at least one block in the buffer to keep a "0" delay in sync anyway, just like a s~/r~ pair.

I tried to test this further with other block sizes and it doesn't seem to work like that. I always get a minimum dealy even with order forcing (and different values depending on extended or vanilla), it seems the delay needs to be at least the block size to work properly - check attachment.

I'd like to suggest then that the delay size is always one block size, even if it is set as "0", and that a "0" length delay works just like a send~/receive~ pair but also for block sizes different than 64 - or even like a tabsend~/tabreceive~ pair.

This is specially useful for pacthes with feedback, it'd be easier than other ways of doing this.

But this seems to touch the issue above regarding the size limit of delay lines: the fact that delread~ can't really read the specified maximum size in delread~

cheers

[Anonymous]

delread~ has limit issues as well, but different ones

[IOhannes m zmölnig]

what does "different ones" mean? please be specific when reporting problems.

[Alexandre Porres]

a patch showing similar issues with delread~