[PD] PVoc patch "bug"?

[Alexandre Torres Porres]

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/90af77de/attachment.html>