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

[Alexandre Torres Porres]

if you check my last patch, I can't see why it would have to be hard not to
make it happen. instead of bothering about the block sizes of the vd~
objects, just make it sure the delwrite~ is at the same block size and it
should work one way or another, if not, it's just a bug. It's bad that you
have a 2048 delay size and can only use 64 samples, bad bad bad.

by the way, that is not the case with objects like z~ and delay~ - so,
again, I just think this is a serious bug that should be fixed. Any
explanation about it is just an explanation why the bug exists, not a
reason for it to exist.

by the way, testing my patch with delread~ shows that it can't delay at
all, while [vd~] at least is able to delay 64 samples.

I've made another patch to show how delread~ doesn't work at all

cheers

2015-09-22 15:08 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:

> > well, I still consider it to be a bug, it's not that it is misleading,
> it is just not happening because of bug.
> > There's nothing to prevent you from reading a delay line to the maximum
> of what it was specified, if it can't, then the object is buggy.
> > If it has some limitation of a block less or so, then there's a simple
> way to fix it, just add an extra block to the delay line and make it work.
>
> Of course Pd COULD allocate 'extra' memory according to the blocksize of
> the reading object, but then it would have to keep track of ALL the objects
> reading from the buffer and the individual blocksizes they are operating
> at. Which would be highly inefficient and give no practical benefit. The
> easier way: changing that sentence in the help file ;-).
>
> But the additional 64 samples were bothering me and after some testing I
> discovered something really weird! I'll write this as a new post to the
> list.
>
>
>
> *Gesendet:* Dienstag, 22. September 2015 um 19:38 Uhr
> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
> *An:* "Christof Ressi" <christof.ressi at gmx.at>, "Miller Puckette" <
> mpuckett at imusic1.ucsd.edu>
> *Cc:* Pd-List <pd-list at lists.iem.at>
> *Betreff:* Re: Delay time limit bug (was: PVoc patch "bug"?)
> here's another example, there's a delay line with a size of 2048 samples,
> in patch with a block size of 2048, and the delay line is only able to
> delay a maximum of 64 samples
>
> 2015-09-22 14:07 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:
>>
>>
>>
>> 2015-09-22 5:56 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:
>>>
>>> You're totally right that the sentence >The delay time is always at
>>> least one sample *and at most the length of the delay line (specified
>>> by the delwrite~)*< is misleading.
>>>
>>
>> well, I still consider it to be a bug, it's not that it is misleading, it
>> is just not happening because of bug. There's nothing to prevent you from
>> reading a delay line to the maximum of what it was specified, if it can't,
>> then the object is buggy. If it has some limitation of a block less or so,
>> then there's a simple way to fix it, just add an extra block to the delay
>> line and make it work. Anyway, I filed this as a bug report yesterday, I
>> hope it gets checked upon soon, hopefully it'll work for the next Pd
>> release (0.47).
>>
>>
>>
>>> BTW: There's a funny issue when the blocksize of the [delread~] is
>>> smaller than the blocksize of the [delwrite~]: In that case the
>>> [delread~] is reading more often than the delay line itself is actually
>>> updated, so you get repetitions of blocks.
>>>
>>
>> Again, i think you can always code it to work around these issues. But in
>> this case, I don't see why not have them both in the same block.
>>
>>
>>
>>> > actually, I made some tests and it is the (buffersize - windows size
>>> + one block 0f 64 samples).
>>> Are you sure?
>>>
>>
>> yep, check the patch I sent, works on vanilla.
>>
>> cheers
>>
>>
>>
>>> *Gesendet:* Montag, 21. September 2015 um 23:05 Uhr
>>> *Von:* "Alexandre Torres Porres" <porres at gmail.com>
>>> *An:* "Christof Ressi" <christof.ressi at gmx.at>, "Miller Puckette" <
>>> mpuckett at imusic1.ucsd.edu>, "pd-list at lists.iem.at" <pd-list at lists.iem.at
>>> >
>>> *Betreff:* Delay time limit bug (was: PVoc patch "bug"?)
>>> > 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/20150922/e389fd47/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delread-test.pd
Type: application/octet-stream
Size: 1242 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150922/e389fd47/attachment-0001.obj>