2016-05-09 18:56 GMT-03:00 Christof Ressi <christof.ressi@gmx.at>:

Pd internally adds 64 samples to the delay time you specify for [delwrite~], so the user will think that buffer size = max. delay time. Here's the relevant part of the code:

static void sigdelwrite_updatesr (t_sigdelwrite *x, t_float sr) /* added by Mathieu Bouchard */
{
int nsamps = x->x_deltime * sr * (t_float)(0.001f);
if (nsamps < 1) nsamps = 1;
nsamps += ((- nsamps) & (SAMPBLK - 1));
nsamps += DEFDELVS;
...
}

where DEFDELVS is defined as 64.

Of course this only works for block sizes of 64 samples.

this is from the new 0.47 version, right?

For me, the only sensible solution is that it knows about the block size and works it out for the user. Having the user to deal with this is just a bad design choice.

> Not so easy I guess

But definitely better once worked out.

> the block size of any reading object can change dynamically - should

> that always trigger a reallocation of the delay line? Probably not...

You're basically looking at a buffer resize, which I don't think is hard, just add or remove samples...

by the way, resseting the delay length as a message would be another feature request I'd be intersted in, besides the clear method.

> [delwrite~] already somehow cares for overlap and oversampling (...).

> But I don't know if it's only when DSP is turned on.

No, whenever you change the overlap, [delwrite~] will change its size in samples. The patch I sent shows this - so it just adds or removes samples

> it's basically a design question

yep. By thinking about it, I guess the sensible thing to do is only care about the block size of where the [delwrite~] is in. Just make it clear in the documentation that a [delread~]/[delread4~] object won't work well if it has a bigger block size.

> I personally like it when everything is as transparent as possible.

me too :)

cheers