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 <[email protected]>: > > 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" <[email protected]> > *An:* "Christof Ressi" <[email protected]>, "Miller Puckette" < > [email protected]> > *Cc:* Pd-List <[email protected]> > *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 <[email protected]>: >> >> >> >> 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 >>>>>> >>>>>
delread-test.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
