[PD] Delay time limit bug (was: PVoc patch "bug"?)

[Alexandre Torres Porres]

> the actual limit of the delay line is the buffersize minus the windows
size

actually, I made some tests and it is the (buffersize - windows size + one
block 0f 64 samples).

But anyway, this limitation is what I perceived, but I fail to see why any
such limitation should happen. If the delay is "x" long, we should be able
to read from "x" behind in time... if not, there's a bug in it. That's how
I see it, and why I marked this issue as a potential bug.

>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 we can't read it at most from the specified delay line, there's a bug!

> since the delay line is only written for every block and you want to read
> the last N samples from the delay line, [vd~] simply clips to the
> maximum reading index.

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

But 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!

I have then the latest version attached. I'm copying miller here and also
sending to the list. I'll also post this as a bug report.

cheers


2015-09-21 16:45 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:

> Hey, as I suspected, you are simply hitting the limit of the delay line.
> You can test this on your own with the patch I've sent you. Note that the
> actual limit of the delay line is the buffersize minus the windows size,
> since the delay line is only written for every block and you want to read
> the last N samples from the delay line. [vd~] simply clips to the maximum
> reading index. Note that there isn't any phase difference anymore between
> the two windows after both have exceeded the limit.
>
> Cheers
>
> *Gesendet:* Montag, 21. September 2015 um 19:53 Uhr
> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
> *An:* "Christof Ressi" <christof.ressi at gmx.at>, "pd-list at lists.iem.at" <
> pd-list at lists.iem.at>
> *Betreff:* Re: Re: PVoc patch "bug"?
> I've simplified the patch a lot so many things can be discarded.
>
> The window size shouldn't affect anything as the reading point in the
> delay line is fixed. Now I don't have [vline~] or anything, just a steady
> signal fed to [vd~], when we get close to the end of the delay line it just
> gets ruined, and that's all that there is to it. There's no flaw in the
> patch, nothing I didn't think of. It's really something very mysterious or
> perhaps a bug.
>
> The patch is now simpler and also vanilla compatible. I tried it in the
> new Pd Vanilla 0.46-7 and I got the same weird behaviour.
>
> Check attachment please
>
> cheers
>
> 2015-09-21 14:12 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:
>>
>> Well, I just think you're hitting the limit of the delay line. Your
>> window size is 2048 samples, so inside the subpatch that's 2048/(44,1*4) =
>> 11,6 ms. But one window is one hop size (2,9 ms) behind, therefore 11,6 ms
>> + 2,9 ms = 14,5 ms and 1000 ms - 14,5 ms = 985,5 ms --> that's pretty much
>> the limit you were experiencing. Hope that helps.
>>
>> Cheers
>> *Gesendet:* Montag, 21. September 2015 um 18:27 Uhr
>> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
>> *An:* "Christof Ressi" <christof.ressi at gmx.at>, "pd-list at lists.iem.at" <
>> pd-list at lists.iem.at>
>> *Betreff:* Re: PVoc patch "bug"?
>> my patch has a little issue, I'm saying the delay line is 60000 ms (this
>> is for the wrapping objects) when it's only 4000, but that is not a problem
>> for what I'm asking here as the wrapping doesn't influence anything. It's
>> just something weird that happens even without the wrapping.
>>
>> I wonder what's the principle you'd have for not using cyclone :)
>>
>> 2015-09-21 12:32 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:
>>>
>>> Hey,
>>>
>>> the first thing I noticed: your [delwrite~] is at 4000 ms, but [s
>>> $0-buff_size] is still fed with 60000 ms... Is this on purpose?
>>> The second thing: Even if you got the range for [pong~] right, my guess
>>> is that this will create a sudden jump from the end of the delay line to
>>> the beginning. You'd need some kind of enveloping to mask the
>>> discontinuity. Maybe this won't be noticeable if you pass the 'problematic'
>>> area quickly, but might sound terrible if you stay there. In your case,
>>> however, it seems that the delay line is simply clipped since you've sent a
>>> wrong value to [pong~].
>>> This is just some remote diagnostics, though, since I don't use any
>>> cyclone objects as a matter of principle :-D.
>>>
>>> Cheers
>>>
>>> PS: I didn't put this on the list on purpose, because it's only about a
>>> specific patch and not something more general.
>>>
>>>
>>> *Gesendet:* Montag, 21. September 2015 um 06:48 Uhr
>>> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
>>> *An:* "pd-list at lists.iem.at" <pd-list at lists.iem.at>, "Christof Ressi" <
>>> christof.ressi at gmx.at>
>>> *Betreff:* PVoc patch "bug"?
>>> Hi there, still struggling with my circular buffer Phase Vocoder, now
>>> I've found an issue that has no apparent reason.
>>>
>>> Check the attached patch please
>>>
>>> the speed is 100% and pitcnh shift is "0", so the signal from vline~
>>> stands still in one particular point in the buffer (read from [vd~]).
>>>
>>> buffer size is 4000 ms, into the PVoc subpatch is supposed to be "1000"
>>> for it does oversampling with the overlap of 4 (we've discussed this
>>> before). Anyway, I'm using sampstoms~ and mstosamps~ to convert in a way
>>> that works for the patch.
>>>
>>> The point is, when getting close to the end of the delay line, things
>>> get ruined for no reason! The end of the buffer is 1000 ms, not 4000 ms as
>>> pointed above. You can check my patch and see how that goes.
>>>
>>> If the reading point is at somewhere just after the buffer size less a
>>> window size plus a hop size (around 985 ms) things get bad.
>>>
>>> I can't find a reason for that in a million years. Please help
>>>
>>> thanks
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150921/8ec2fd41/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delay-limit-issue.pd
Type: application/octet-stream
Size: 41672 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150921/8ec2fd41/attachment-0001.obj>