[PD-dev] [pure-data:bugs] #1217 delay size limit bug

[Alexandre Porres]

---

** [bugs:#1217] delay size limit bug**

**Status:** open
**Group:** v0.46
**Labels:** delay 
**Created:** Tue Sep 22, 2015 04:49 AM UTC by Alexandre Porres
**Last Updated:** Tue Sep 22, 2015 04:49 AM UTC
**Owner:** Miller Puckette
**Attachments:**

- [Delay-limit-bug.pd](https://sourceforge.net/p/pure-data/bugs/1217/attachment/Delay-limit-bug.pd) (11.2 kB; application/octet-stream)


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.


---

Sent from sourceforge.net because pd-dev at lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150922/6818e25f/attachment.html>