[PD] PVoc patch "bug"?

[Alexandre Torres Porres]

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/95234c5a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pvoc-Vanilla.pd
Type: application/octet-stream
Size: 24752 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150921/95234c5a/attachment-0001.obj>