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 <[email protected]>: > 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" <[email protected]> > *An:* "[email protected]" <[email protected]>, "Christof Ressi" < > [email protected]> > *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 >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
