And I think the same logic will apply to any [delread~] buffer explicitly set to <= 60 samples ([delread~] rounds up from the input to the nearest multiple of 4).
On Sat, Dec 12, 2015 at 4:49 PM, Matt Barber <[email protected]> wrote: > There's one trick that works for zero delay and [delwrite~ 0], based on > the code of [delread~]: provide a negative delay time (with abs(delay time) > > 1 sample). > > Here's what's going on in Alexandre's patch. > > [delwrite~ 0] sets up a buffer that is 68 samples long, plus four extra > for interpolation in [vd~], which we needn't worry about here. > > delwrite's float method is this: > > > /*---------------------------------------------------------------------------*/ > static void sigdelread_float(t_sigdelread *x, t_float f) > { > int samps; > t_sigdelwrite *delwriter = > (t_sigdelwrite *)pd_findbyclass(x->x_sym, sigdelwrite_class); > x->x_deltime = f; > if (delwriter) > { > int delsize = delwriter->x_cspace.c_n; > x->x_delsamps = (int)(0.5 + x->x_sr * x->x_deltime) > + x->x_n - x->x_zerodel; > if (x->x_delsamps < x->x_n) x->x_delsamps = x->x_n; > else if (x->x_delsamps > delwriter->x_cspace.c_n - DEFDELVS) > x->x_delsamps = delwriter->x_cspace.c_n - DEFDELVS; > } > } > > /*---------------------------------------------------------------------------*/ > > Here, I believe that because the write and read are sorted, x->x_zerodel > == 0. Also DEFDELVS == 64, and delwriter->x_cspace.c_n == 68; > So with [delread~ 0], x->x_delsamps is initialized to 0 + 64 - 0. The > first if statement fails, but the second one passes, and x_delsamps is set > to c_n - DEFDELVS = 4. > > Let's pick it up after [delwrite~]'s second block calculation. It's just > gotten the range 64:127 in its input vector, and written indices 64:67 with > 64:67, and indices 0:59 with 68:127. Its phase is now at index 60. With > x_delsamps set to 4, [delread~ 0] begins reading at index 60-4 = 56, which > contains the value 124. For four samples, the difference between input and > output (the [-~] in the patch) is -60. Indices 60:67 contain values 60:67, > and 0:59 contain 68:127; the difference between input and output is > therefore 8 for the 60 remaining samples of the block. Hence the > oscillation between 8 and 60 in the number box, with 8 appearing most of > the time. > > If you set a negative delay, the first if statement passes, and x_delsamps > is set to 64, as it should be to get zero delay (that is, it's reading the > last 64 samples written to the delay buffer, so there's zero difference > between input and output). > > Matt > > > > > On Sat, Dec 12, 2015 at 12:00 PM, Alexandre Torres Porres < > [email protected]> wrote: > >> > Order forcing works well for me. Just set the [delwrite~] to 10 ( >> >> but weirdness arises from 0 length delay. >> >> > If a delay of zero WAS actually permitted, these would form infinite >> loops. >> >> Don't think so, depends on what a 0 delay is. If it is "no delay", and by >> that I mean "No Buffer", then it only outputs 0 values, right?. In other >> words, nothing happens, no infinite loop, nothing, just zeros... >> >> but if instead of zeros it does have some buffer length in it, then a >> feedback delay will always de delayed at least one block size, so no >> worries about feedback loop. >> >> Actually, you need to set delread to "0" for a minimum block size delay. >> Perhaps you meant you couldn't or shouldn't put a "0" delay time in the >> delread~ object for feedback, but actually you NEED to do that. >> >> Thing is that I just use delwrite~ and delread~ with 0 length arguments >> for both and a block size of 1 to allow single sample feedback. I do it >> cause I wanted the minimum delay buffer size as possible and I didn't want >> to write in tiny and long and boring numbers according to one sample size >> depending on sample rate. >> >> Since it was working, I had just always assumed it would create a buffer >> of one block. >> >> This is not what's really happening as I see it. >> >> I don't really care that much on what happens, doesn't seem like a big >> deal, but it was nice to understand this behaviour. It doesn't seem very >> consistent, that's all I can say... >> >> Now, what it actually does is really just a matter of design choices. It >> could very much just create no delay buffer at all, where you'd get 0 >> values perhaps, like I imagined. That's silly anyway... >> >> Or... it could be only one sample... or one block... I had assumed out of >> nowhere that it could be a block size, but it could much be just a single >> sample, which seems to make sense and it'd be cool I guess. >> >> What's really bad is that you need to always put a value that is at least >> one block size. It's a bug considering the documentation clearly stated >> that the design was really supposed to be a delay between 0 and max delay >> size, but one way or another, it's really annoying doing all this math >> as a workaround, when it's just a matter of coding it properly to allow any >> size greater than 0 and smaller than a block size (in orther words, to fix >> it). >> >> > If you, however, want a simple block delay in a feedback loop, >> > just use a pair of [send~] and [receive~]. >> >> don't work for block size < 64 >> >> > specifying the buffer size makes much more >> > sense then giving a maximum delay time >> >> Those two things means the same to me, where maximum delay time = buffer >> size. I don't get this. >> >> > [delwrite~] object would need to keep track of this >> >> sure, whatever, why not? >> >> by the way, that's the one that defines the max delay length (or buffer >> size), (and there can be only one, by the way) - so it only needs to keep >> track of its block size to work out the proper buffer size. >> >> I might see an issue if delread~ is in a subpatch that has a longer block >> size, but I don't wee why anyone would need that, and perhaps just say you >> shouldn't do it. >> >> I think we've discussed this before, perhaps just make sure both are in >> the same block size. I for one, never needed them to be in different block >> sizes, makes no useful sense. >> >> But anyway, I guess Miller is the one that should hop in and share his >> thoughts. >> >> and lets not forget the "clear" method, also important :) >> >> cheers >> >> >> 2015-12-12 12:33 GMT-02:00 Roman Haefeli <[email protected]>: >> >>> >>> On Fri, 2015-12-11 at 14:26 -0200, Alexandre Torres Porres wrote: >>> > hi, I'm checking that if you put a 0 length delay in delwrite~ you >>> > still have some buffer >>> > >>> > >>> > what's up with that? and how does it work? how big is it when you >>> > don't define it? >>> >>> Don't know. I confirm that weirdness happens when setting [delwrite~] to >>> 0. In other words: The only value that does not justify using a delay at >>> all shows unexpected behavior. I can live with that. >>> >>> > I always get a minimum dealy even with order forcing (and different >>> > values depending on extended orvanilla), it seems the delay needs to >>> > be at least the block size to work properly >>> > >>> > >>> > moreover, I can't have an order forcing >>> >>> Order forcing works well for me. Just set the [delwrite~] to 10 (and >>> [delread~] to 0) in your patch and the number box shows 0 (this means >>> zero delay, right?). >>> >>> Roman >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
