2015-09-22 5:56 GMT-03:00 Christof Ressi <[email protected]>: > 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" <[email protected]> > *An:* "Christof Ressi" <[email protected]>, "Miller Puckette" < > [email protected]>, "[email protected]" <[email protected]> > *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 <[email protected]>: >> >> 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" <[email protected]> >> *An:* "Christof Ressi" <[email protected]>, "[email protected]" < >> [email protected]> >> *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 <[email protected]>: >>> >>> 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" <[email protected]> >>> *An:* "Christof Ressi" <[email protected]>, "[email protected]" < >>> [email protected]> >>> *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 <[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
